GNOME Bugzilla – Bug 747649
No sound in VMs
Last modified: 2016-09-20 08:15:55 UTC
Created attachment 301318 [details] QEMU troubleshoot log After installing the most recent stable version of Xubuntu as a VM I noticed that there was no sound.This seems to differ from bug 666599 so I'm filing a new one.
Same with it. Windows 7 protocol, in the gnome-boxes window-in SPICE is not have sound. but Run spicec -h localhost -p 5900 in terminal is have sound.
On ArchLinux with libvirt 1.2.14-2, qemu 2.2.1-4 and gnome-boxes 3.16.1-1 with a Windows 7 VM, there is no sound in the gnome-boxes window, but as MayKiller says, spicec -h localhost -p 5900 in terminal have sound, as virt-manager 1.1.0 on the same VM.
Ok, I can reproduce this issue with every box. The issue goes away if I revert: https://git.gnome.org/browse/gnome-boxes/commit/?id=fb04e17a7dac24ecb14b2b0d252f025841cef075 So this is most likely introduced by this and its grand-parent commit: https://git.gnome.org/browse/gnome-boxes/commit/?id=9268e023c3747e552c8047cb05bac76e1328613a I wish the API involved weren't so hard to get right or nicely documented. :(
Turns out it needed to be fixed in spice-gtk. Developers already have a fix that i tested so it'll be there in the next spice-gtk release.
FYI while spice-gtk has not seen an upstream release and developers don't believe in releasing to get fixes out, the fixes had been ported to Fedora 22 so please point that out to your distro packagers so they also include those fixes too.
(In reply to Zeeshan Ali (Khattak) from comment #5) > FYI while spice-gtk has not seen an upstream release and developers don't > believe in releasing to get fixes out, the fixes had been ported to Fedora > 22 so please point that out to your distro packagers so they also include > those fixes too. Sigh.. Not what we said! both Christophe and I said this could be done. It's just that nobody has stand up (and enough time) to maintain a stable branch upstream. However, we have to maintain the Fedora release, so this is where the critical fixes go in general.
You could also recognize that enabling a feature that doesn't work is also your responsability as a user of spice-gtk and maintainer of Boxes: this is not a regression on spice-gtk side. Imho, stable Boxes release deserve a fix too, and it's probably the first thing to do here instead of bothering everybody to update to a upcoming spice-gtk.
(In reply to Marc-Andre Lureau from comment #6) > (In reply to Zeeshan Ali (Khattak) from comment #5) > > FYI while spice-gtk has not seen an upstream release and developers don't > > believe in releasing to get fixes out, the fixes had been ported to Fedora > > 22 so please point that out to your distro packagers so they also include > > those fixes too. > > Sigh.. Not what we said! both Christophe and I said this could be done. I only saw Christophe's reply after my comment but thing is I've been asking for a release for months now and seems its not considered urgent enough to make critical fixes available upstream for all distros. > It's > just that nobody has stand up (and enough time) to maintain a stable branch > upstream. > However, we have to maintain the Fedora release, so this is where > the critical fixes go in general. Is creating a branch and releasing out of that really a lot that work compared to backporting fixes to Fedora?
(In reply to Marc-Andre Lureau from comment #7) > You could also recognize that enabling a feature that doesn't work is also > your responsability as a user of spice-gtk and maintainer of Boxes: Which feature? The unix socket patches? You reviewed that work and of course those changes were made to unstable (which later became stable): https://bugzilla.gnome.org/show_bug.cgi?id=738573 > this is > not a regression on spice-gtk side. Imho, You (as spice-gtk dev) enable a feature A (which is more like a big security fix) and are fully aboard the idea of Boxes making use of that feature and later it turns out that use of this feature breaks two other existing features. That is an issue in spice-gtk, whether you classify it as regression or not. > stable Boxes release deserve a fix > too, What fix does Boxes need? Fixes in spice-gtk solves the issue so I don't why Boxes should change anything. > and it's probably the first thing to do here instead of bothering > everybody to update to a upcoming spice-gtk. So Boxes can be magically fixed without any action from user while spice-gtk fixes can't? :)