Red Hat Bugzilla – Bug 658359
Could not hear the sound in guest which connected by VNC
Last modified: 2011-01-14 07:28:28 EST
Description of problem:
Could not hear sound in guest which use VNC to connect.
but can hear the sound when connect the guest via spice.
Use the same driver in above two conditions, QEMU_AUDIO_DRV=alsa
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run QEMU_AUDIO_DRV=alsa
2. start guest with
/usr/libexec/qemu-kvm -m 2G -smp 2 -uuid `uuidgen` -monitor stdio -boot c -drive file=/home/winxp-32.raw,if=ide,bus=0,unit=0,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:73:b5:90,model=rtl8139,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -usb -vnc :2 -soundhw ac97
3. to hear the sound from guest
Could not hear sound in guest
The message display in monitor:
line_out_init: freq 44100 channels 2 format AUD_FMT_S16 HOST_ENDIANNESS
can hear the sound in guest
Can hear the sound in guest which use spice to connect.
/usr/libexec/qemu-kvm -m 2G -smp 2 -uuid `uuidgen` -monitor stdio -boot c -drive file=/home/winxp-32.raw,if=ide,bus=0,unit=0,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:73:b5:90,model=rtl8139,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -usb -spice disable-ticketing,port=5930 -qxl 1 -soundhw ac97
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of
Red Hat Enterprise Linux. The error has been fixed and this
request has been re-proposed for the current release.
QEMU_AUDIO_DRV=alsa is broken, bug in the spice patches, spice (in rhel5) grabs the audio output unconditionally and QEMU_AUDIO_DRV=<anything> has no effect at all.
Fixing this would *not* make the sound play on the vnc client machine, but on the host where the VM is running, which is probably not the desired effect.
Fixing this also has the risk of adding regressions because alsa devices can't be shared and thus two VMs trying to play sound could conflict with each other.
Beside that this is not a supported configuration.