This is a bug to track qemu/kvm VNC audio support in gtk-vnc. Currently, getting audio to work with VMs in fedora is total crack; seamless out of the box support with VNC would be really slick. Older info about a similar Fedora feature: http://fedoraproject.org/wiki/Features/VirtVNCResourceTunnel
*** Bug 477955 has been marked as a duplicate of this bug. ***
Thanks for updating the bug. Is this feature targeted for inclusion in F14? - Gilboa
Not explicitly, but AFAIU the gtk-vnc code is mostly complete, it just had some issues with audio skipping. I'm hoping to dust off the code and at least get it into F14, even if the result is less than perfect.
Is it testable in any form under F13 (Even by rebuilding rawhide SRPMs)? Will it work with qemu-kvm proper (Read: without virt-manager)? Thanks again.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Has this code been added to the latest f14 test build i.e. gtk-vnc-0.4.1-6, and will it work in conjunction with virt-manager? Thanks. If the patch has not been added, is there a git repo, where I can pull it down, thanks.
I'd like to propose this for F14Target. I don't know if that's possible at this point, or if it's possible to get the changes in time, but having functional sound in guest VMs would certainly make Fedora appear more polished. Lack of functional guest sound makes it appear unpolished.
Could we get a status update on this issue to see if it would make sense to work on a patch independently? Thanks! David
This is available in the GTK-VNC in Fedora 17. I don't have plans to backport to older Fedora.
Cool, congrats on finally landing it. Is there anything we need to do in virt-manager to enable this or does it just happen automagically?
No it isn't automatic, since you have to pick an audio output target - currently PulseAudio is the only option. The slight complication for virt-manager, is that to access this functionality you'd need to by using the GObject introspection based bindings, instead of the legacy python binding. API-wise they are a pretty close match, so I think it ought to be possible to make the code work with both the legacy & Introspection based bindings at the same time. Obviously audio would only be supported for the latter. I'll try and do a patch for virt-manager, since this isn't really documented
Can we mix and match gobject introspection with gtk2? I tried to port virt-manager to vte3 with introspected bindings and gtk complained with an error to that effect, which sucks. But end result is I'll be looking into a gtk3 port sooner rather than later.
Yes, introspection is independent of the GTK version, so you can still use it with Gtk2.
> > Can we mix and match gobject introspection with gtk2? > Yes, introspection is independent of the GTK version, so you can still use it > with Gtk2. Fate conspires against us. While it is possible to mix it at a C level, the life isn't so nice at the Python level. The Pygobject bindings will refuse to allow mixing of the traditional manual bindings, with the new GOBject bindings. The upshot is we can't use the GTK-VNC GObject dynamic bindings, without converting the rest of virt-manager to also use the new GObject bindings :-( Seems like the only options will be to switch virt-manager master branch wholesale to dynamic GObject bindings, at which point you might as well use GTK3 too. For any platforms predating Fedora 16, we'd need to maintain some kind of "stable branch" for the previous virt-manager release.