kvm: use PulseAudio instead of ALSA

[Arie Skliarouk]

Binary package hint: kvm

kvm in jaunty prefers to use OSS drivers rather than ALSA:
# dpkg -l | grep kvm
ii kvm 1:84+dfsg-0ubuntu11 Full virtualization on i386 and amd64 hardwa
# kvm -audio-help | grep ^Name
Name: oss
Name: alsa
Name: sdl
Name: pa
Name: none
Name: wav
#

Because of that, once a virtual machine with working audio card starts, the kvm grabs the audio card entirely for itself. Any subsequent operations on audio card either from the host machine, or from the other audio-enabled virtual machines lock up (apparently awaiting on on access to the audio card).

The bug is echo of the corresponding debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508018

[Arie Skliarouk (skliarie)]

So we are waiting for the kvm 85+dfsg-4 to be ported over to ubuntu...

Will the resulting package be backported to Jaunty?

[Dustin Kirkland  (kirkland)]

Actually, I do not intend on merging kvm-85 for Karmic.

Instead, I plan on packaging qemu-kvm, which is a stable branch of the
qemu tree with kvm support.

If you'd like to test the daily upstream builds, see:
 * https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream

I'll try to address this bug with the new packaging.

:-Dustin

[Arie Skliarouk (skliarie)]

Excellent!
Please write a note in the bug report when the new packaging is in the repository.

[Dustin Kirkland  (kirkland)]

This should be fixed in the karmic qemu-kvm package.

Thanks.

:-Dustin

[Arie Skliarouk (skliarie)]

After installation of qemu-kvm package from karmic (version 0.11.0~rc2-0ubuntu9) the situation is better, as order of the audio driver has changed (I am not sure that it matters):
# kvm -audio-help | grep ^Name
Name: alsa
Name: pa
Name: oss
Name: sdl
Name: none
Name: wav
#

I hear audio on host machine (pulseaudio is running).
Any operations on audio card from audio-enabled virtual machines lock up (apparently awaiting on on access to the audio card).

KVM uses pulseaudio:
# lsof | grep kvm | grep puls
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/gavri/.gvfs
      Output information may be incomplete.
kvm 5221 root mem REG 8,1 389688 12067104 /usr/lib/libpulse.so.0.7.1
kvm 5221 root mem REG 8,1 72992 12067250 /usr/lib/libpulse-simple.so.0.0.2
kvm 5231 root mem REG 8,1 389688 12067104 /usr/lib/libpulse.so.0.7.1
kvm 5231 root mem REG 8,1 72992 12067250 /usr/lib/libpulse-simple.so.0.0.2
kvm 7921 root mem REG 8,1 389688 12067104 /usr/lib/libpulse.so.0.7.1
kvm 7921 root mem REG 8,1 72992 12067250 /usr/lib/libpulse-simple.so.0.0.2
#
# ps awx | grep 7921
 7921 ? Sl 0:31 /usr/bin/kvm -S -M pc -cpu qemu32 -m 512 -smp 1 -name gavri-xp -uuid affe5dd7-8576-370b-80ed-50f50d0b5dbe -monitor unix:/var/run/libvirt/qemu/gavri-xp.monitor,server,nowait -localtime -no-acpi -boot c -drive file=/var/tmp/vmachines/gavri-xp.img,if=ide,index=0,boot=on -drive file=/var/tmp/vmachines/winxp_sp2.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:16:97:75,vlan=0,name=nic.0 -net tap,fd=28,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:1 -k en-us -vga cirrus -soundhw es1370
#

[Arie Skliarouk (skliarie)]

I did dist-upgrade and now the situation is the same as in the bug description, so we are squarely at the beginning:

... once a virtual machine with working audio card starts, the kvm grabs the audio card entirely for itself. Any subsequent operations on audio card either from the host machine, or from the other audio-enabled virtual machines lock up (apparently awaiting on on access to the audio card).

# lsof | grep snd
kvm 2085 root mem REG 8,1 385016 12068460 /usr/lib/libsndfile.so.1.0.20
kvm 2093 root mem REG 8,1 385016 12068460 /usr/lib/libsndfile.so.1.0.20
kvm 5343 root mem CHR 116,7 3967 /dev/snd/pcmC0D0c
kvm 5343 root mem REG 8,1 385016 12068460 /usr/lib/libsndfile.so.1.0.20
kvm 5343 root mem CHR 116,6 3963 /dev/snd/pcmC0D0p
kvm 5343 root 20r CHR 116,2 0t0 3859 /dev/snd/timer
kvm 5343 root 21u CHR 116,6 0t0 3963 /dev/snd/pcmC0D0p
kvm 5343 root 22u CHR 116,9 0t0 3971 /dev/snd/controlC0
kvm 5343 root 23r CHR 116,2 0t0 3859 /dev/snd/timer
kvm 5343 root 24u CHR 116,7 0t0 3967 /dev/snd/pcmC0D0c
kvm 5343 root 25u CHR 116,9 0t0 3971 /dev/snd/controlC0
gnome-set 5541 gdm mem REG 8,1 385016 12068460 /usr/lib/libsndfile.so.1.0.20
pulseaudi 5559 gdm mem REG 8,1 385016 12068460 /usr/lib/libsndfile.so.1.0.20
gconf-hel 5561 gdm mem REG 8,1 385016 12068460 /usr/lib/libsndfile.so.1.0.20
#

I though that alsa interface to sound card allows several users simultaneously...
Will running kvm with pa (pulseaudio) driver solve the problem? How can I do that?

[Dustin Kirkland  (kirkland)]

Argh...

Okay, I'll revert that last patch.

:-Dustin

[Arie Skliarouk (skliarie)]

Can kvm launch qemu with pulseaudio driver, so that audio could be heard both from native Linux machine and from the windows machine?

Currently kvm launches qemu with ALSA driver. By then, the ALSA soundcard is taken by pulseaudio and qemu has no luck to open the audio device for itself.

If I kill pulseaudio daemons (not an easy task, believe me), and then start the qemu, I am able to hear the audio produced by the windows instance, but not the native linux machine.

It would be very sad if the bug would remain in karmic...

[Dustin Kirkland  (kirkland)]

Arie-

Are you still seeing this bug in Karmic"

I see:

$ kvm -audio-help | grep ^Name
Name: alsa
Name: pa
Name: oss
Name: sdl
Name: none
Name: wav

Also, to answer your last question, you can in fact force a particular driver with:
export QEMU_AUDIO_DRV=pa

And then launching kvm.

Can you try that?

[Arie Skliarouk (skliarie)]

I added "export QEMU_AUDIO_DRV=pa" to the /etc/default/libvirt-bin and looks like that the parameter is passed to the KVM, as the KVM does not use the /dev/snd/* directly. But then audio from KVM works for couple of seconds only (enough to hear the startup audio from windows, but not much more than that)! Also, in this case the KVM does not appear in list of the pulse-audio configuration applet (under Running applications).

If I use "export QEMU_AUDIO_DRV=alsa" in /etc/default/libvirt-bin, then KVM uses the /dev/snd/* devices and audio from the KVM works (with all the known limitations).

[Arie Skliarouk (skliarie)]

Hmm, yesterday sound from KVM+ALSA worked for the whole day (using "export QEMU_AUDIO_DRV=alsa") but today the audio from KVM works for couple of seconds only (enough to hear the startup audio from windows only)!

This is repeatable each time I shutdown and start the windows XP SP2 virtual machine...

[Dustin Kirkland  (kirkland)]

Hmm, I think upstream does prioritize pa over alsa. Marking incomplete, need to check that.

[Arie Skliarouk (skliarie)]

KVM on lucid appears to prioritize pa:
#kvm -audio-help | grep ^Name
Name: pa
Name: alsa
Name: sdl
Name: oss
Name: none
Name: wav

but in effect alsa is still used... could it be related to the fact that by default pulse-audio daemon is started per user, whereas kvm starts the virtual machines before user has a chance to login?

[Dave Walker (davewalker)]

The Debian big referenced suggested using ALSA over OSS, this bug is related to favouring PA over ALSA. The Debian issue was resolved with:

--- kvm-79+dfsg/debian/rules
+++ kvm-82+dfsg/debian/rules
@@ -141,7 +141,9 @@
 config.status: configure
  dh_testdir
  # Add here commands to configure the package.
- ./configure --prefix=/usr
+ ./configure --prefix=/usr \
+ --audio-drv-list="alsa oss sdl" \
+ --audio-card-list="ac97 adlib cs4231a gus"

 build-arch: patch config.status build-arch-stamp

However, the current debian qemu-kvm package contains:
                    --audio-drv-list="alsa oss sdl pa" \
                    --audio-card-list="ac97 es1370 sb16 cs4231a adlib gus hda" \

Neither of these configure options are set in debian/rules. This probably requires further investigation.

Thanks.

[Serge Hallyn (serge-hallyn)]

Can someone post a good test case, and expected and actual results at this point? Maybe an upstart job running

  kvm --audio-help | grep ^Name

so that no user is logged in yet (per comment #14)?

[Clint Byrum (clint-fewbar)]

Bump, fairly old issue here. I wonder if anybody is still affected on recent releases of Ubuntu (including 10.04 but also 11.10 and precise.)

[Peter Maydell (pmaydell)]

(ancient distro packaging bug so never valid for QEMU upstream itself; marking Invalid there)