Sound Device Problem in VMware Workstation 7

I was running Windows XP as a guest in a virtual machine (VM) in VMware Workstation 7 on an Ubuntu 9.10 (Karmic Koala) host.  When I used Workstation's VM > Removable Devices > Sound Card > Connect option, I got this error message:

Failed to open sound device /dev/audio:  Device or resource busy
Failed to connect virtual device sound.

I had also gotten this message:

Failed to open sound device /dev/dsp: Device or resource busy
Sound will not be available

I had been having this problem ever since I started using VMware.  I had previously changed the sound device (using VM > Settings > Hardware tab > Sound Card > Use physical sound card) from /dev/dsp to /dev/audio, and had also changed the sound card so that it would not connect at power on.  These and other efforts (e.g., rebooting) had fixed things temporarily, but then stopped working.

Some time back, I had found that I got this problem when Second Life was running in Ubuntu (that is, not in the WinXP guest).  More recently, I had had the same problem when Firefox was running in Ubuntu.  What I worked out that time was as follows:

For the time being, the solution seems to be either (a) to watch videos and other webpages that use Flash, do it in a browser session that is running inside your VM, not in a browser running in Ubuntu, or (b) after watching a video or otherwise using Flash in Ubuntu, kill the program that used it (e.g., Firefox) and manually reconnect with your sound card inside the VM.

So now I powered down my VM (i.e., not just suspended) and went into Workstation's VM > Settings > Sound Card option.  There, I put my settings at "Connect at power on" and Use physical sound card:  Auto detect.  I saved that and killed all browsers in Ubuntu, including Firefox and also Google Chrome.  I then powered on the VM.  WinXP had a hard time booting itself -- it always seemed to reboot a couple of times before it finally got itself together -- so while I was waiting, I started another session of Workstation and, in that one, I set the sound card to "Use physical sound card:  ALSA: Default sound card," and powered up that VM as well.  That one booted.  The one set to Auto Detect seemed frozen, so I changed it to "Use physical sound card:  OSS:  /dev/dsp" and tried again.  It gave me a notice that VMware Tools was not installed (it had been installed previously), but it booted, and Tools did appear to be running OK.

At this point, sound was working OK in the one that used ALSA, but not in the one using OSS.  That is, when I tried the virtual machine that was using VM > Removable Devices > Sound Card > Connect in the OSS, I got an error message.  I changed it to ALSA, like the other one, and then the sound worked in both.  The solution reached previously, of killing competing programs in Ubuntu, seemed to be the answer again.

Later, though -- after rebooting, I think, and anyway after running Firefox in Ubuntu again -- I found the audio was stuttering.  It stuttered at different speeds if I used ALSA or OSS, but either way it stuttered.

I played a sound file in the VM, and while it was stuttering along, I went to Ubuntu's System > Preferences > Sound > Applications tab.  There, I saw "ALSA plug-in [vmware-vmx]" listed, and underneath it I saw "No application is currently playing or recording audio."  That message was flickering on and off with each stutter in the sound.  A search along these lines led to a thread in which someone suggested reinstalling the ALSA packages.  In System > Administration > Synaptic Package Manager I did a quick search for ALSA.  I saw that I had a number of ALSA-related programs installed.  I started to mark one of them, alsa-base, for removal, but when I did so, Synaptic indicated that it would also need to remove a package called ubuntu-desktop.  That sounded pretty major, so I bailed out of the reinstall-ALSA approach.

I did a different search and came up with a thread in which someone said that VMware Workstation 7 supports ALSA perfectly, and if you are getting stuttering it may be because of a setting in the WinXP guest, not in Ubuntu or Workstation.  Following the advice there, I went into XP's Control Panel > Sounds and Audio Devices > Volume tab > Speaker settings > Advanced > Performance tab.  There, as advised, I set both the Hardware Acceleration and the Sample Rate Conversion Quality sliders to the lowest possible settings.  I clicked Apply and OK and then rebooted the XP guest.  With ALSA as the chosen sound card setting, and with the sound card connected in VM > Removable Devices > Sound Card, I found on reboot that I had no sound at all.  I tried changing from ALSA to OSS and auto detect and back to ALSA.  Now I could connect the sound card, and now I had sound.  But I still had stuttering.  I tried typing “/dev/audio” into the box in place of ALSA, and (after reconnecting the sound card) that sped up the stuttering but did not eliminate it.

I wondered if the stuttering was due to a larger problem with the VM.  I wondered this because its performance was generally slow at this point, and had been slow before I started this latest round of tinkering.  (In other words, I hadn’t caused that slowness just by playing with the sound problem.)  I suspended the VM and shut down the system.  Next day, I started the machine and tried again.  There was still a bit of stuttering, but the situation was much better.  (See also this other writeup on audio problems in Ubuntu and VMware.)

Ubuntu 9.04, VMware Workstation 6.5.2: Failed to Open Sound Device

I wanted to have multiple virtual machines (VMs) open at once in VMware Workstation 6.5.2, running on 64-bit Ubuntu 9.04 (Jaunty Jackalope). If I tried to do this in a single session of Workstation, it would crash or malfunction whenever I tried to close or suspend or de-maximize one of the VMs. The workaround I arrived at was to open multiple sessions of Workstation, each dedicated to just one VM.

After starting to use this approach, I got an error message telling me that I had too many VMs. I didn't write down the exact wording of that message, but shortly thereafter I got another one, one that I had encountered previously: trying to play sound in a VM gave me a "Failed to open sound device /dev/dsp" error message.

At about the same time, it seems, there was a new version of VMware Tools. I installed that on each of my VMs. I don't know if that new version materialized before or after this audio problem, or whether it was involved in the creation or solution of this audio problem.

I first tried an approach that I had tried before: replace "/dev/dsp" or "Auto detect" with "/dev/audio" in each VM. To change that, I had to power down (not just suspend) each VM, close Workstation, and then start Workstation again as root (i.e., type "sudo vmware" at the Terminal prompt). Then, in Workstation, go to VM > Settings > Sound Card > Use physical sound card. There, type in "/dev/audio" and save. Then save. Repeat for each VM. Then exit and restart Workstation as an ordinary user.

At first, that seemed to solve it for me, but then the problem returned, so I tried the suggestion to (1) install "paprefs" in Synaptic, (2) go to Ubuntu's System > Preferences > PulseAudio Preferences, (3) check the top-level boxes on all three tabs, and (4) reboot. Then, in each VM, I went to VM > Removable Devices > Sound Card > Connect. This time for sure: I was able to hear audio in each VM. But then, after a day or two of using the system, I was getting a "Failed to open sound device /dev/audio" error message.

The rest of the message, at least in this case, was, "Device or resource busy. Failed to connect virtual device sound." "Busy" seemed to imply that another VM, or Ubuntu itself, was hogging the sound resource. The sound card device was disconnected in all three of the VMs I had open at that time, but I was getting sound in Ubuntu (System > Preferences > Sound > Test). It seemed the problem might apply to VMware generally. To make sure VMware was able to access my soundcard, nxmehta suggested these steps:

sudo apt-get install alsa-oss

echo '#!/bin/bash' > ~/vmware

echo 'LD_PRELOAD=libaoss.so exec /usr/bin/vmware.orig "$@"' >> ~/vmware

sudo mv /usr/bin/vmware /usr/bin/vmware.orig

sudo mv ~/vmware /usr/bin/vmware

sudo chmod 755 /usr/bin/vmware

sudo chmod +s /usr/lib/libaoss.so.*

I tried them and they didn't work. Rereading his post, I guessed (he didn't actually say) that I should have shut down VMware before trying. When I rebooted and connected the sound card again (VM > Settings), it worked. But the next day, after a bit of usage and another reboot, it was giving me stuttering sound. This was happening even when I was using only one VM. Another thread had a couple of suggestions, including installing a second sound card dedicated to VMware. The suggestion I tried, from that thread, called for typing "sudo gedit /etc/pulse/daemon.conf" and then changing some settings, as follows:

high-priority = yes

nice-level = -11

realtime-scheduling = yes

realtime-priority = 5

default-fragments = 4

default-fragment-size-msec = 4

resample-method = speex-float-3

Some of these changes were already made in my daemon.conf file, but realtime-scheduling was originally no, resample-method was src-linear, default-fragments was 8, and default-fragment-size-msec was 10. I unintentionally made these changes while VMware Workstation was still running. All of my VMs were either suspended or powered down. I then exited and restarted Workstation and fired up one of the powered-down VMs in which I had just encountered stuttering audio. The audio was still stuttering. Someone suggested that the problem may have arisen because s/he did an upgrade rather than a clean installation of Ubuntu 9.04, but in my experience I did have days of successful use of audio on the upgraded system before this started happening. Moreover, I was not having the stuttering audio problem when I played audio in Ubuntu, only when I played it in a Windows XP VM.

In case it was a Windows problem, I installed the K-Lite Mega Codec Pack in my WinXP VM and rebooted but, alas, this did not prove to be the silver bullet, and the problem occurred regardless of whether I played audio in IrfanView, Windows Media Player, or Media Player Classic. I powered up another VM that had been suspended during the foregoing operations and verified that it, too, was still having the stuttering problem.

Several days passed. It seemed that I would have to go back through the various suggestions, correct my mistakes, re-try what I had seemingly done right, and keep digging for more solutions. This, I knew, could be a huge time sink. I decided instead to see if I could find an alternative. Since I wanted to reduce my dependence on Windows anyway, I looked into the possibility of using IrfanView, at least, on Ubuntu itself, via Wine. That investigation is the subject of another post which, like this one, appears in my blog this month.