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 <freddy77@xxxxxxxxx> 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,FredianoIl giorno sab 29 gen 2022 alle ore 05:32 Neal Piche <phirestalker@xxxxxxxxx> 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?