Yes, it is local, and the scenario is how you explained. I ran the QEMU only test with QEMU installed from homebrew, but spice does not work on that QEMU for M1 macs, so I normally use UTM. I filed a bug there, but he is just launching QEMU as far as I can tell. Although, I don't know what version he is using.
On Sat, Jan 29, 2022 at 2:53 AM Frediano Ziglio <fredd...@gmail.com> wrote: > Hi Neal, > what is the exact environment? Is it everything local and are you using > the default Qemu interface? Or are you running Qemu and attacking with > spice-gtk, remote-viewer, virt-manager or any other remote desktop > application? If I understood correctly the desktop application, running on > Mac, is not following the system changes to the audio output device, right? > So for instance you attach an external bluetooth speaker to your Mac, set > the output to the bluetooth speaker, all applications are now using the > bluetooth speaker beside the spice desktop application. > > Regards, > Frediano > > > Il giorno sab 29 gen 2022 alle ore 05:32 Neal Piche < > phirestal...@gmail.com> ha scritto: > >> I am on macOS. Most applications are able to accept changes to the audio >> device from the system and output sound to that device. >> >> I use QEMU, and if I leave spice extensions disabled, the guest OS is >> able to accept changes to the audio device multiple times. When I turn on >> spice extensions, QEMU will try to continue outputting sound to the >> original device. No matter what I change the output device to, it will keep >> whatever it had originally. I don't know if it is QEMU using spice >> incorrectly, a misconfiguration, or a bug in one of the spice packages. >> >> Oh, I have tried with a Debian bullseye and Whonix guest with the same >> results. >> >> Has anyone found a workaround? Should I file a bug, and if so where? >> >
