Ubuntu 9.10, VMware Workstation 7: Failed to Open Sound Device (Workaround)

In previous posts, I tried fixing error messages that I was getting in a Windows XP virtual machine (VM) running on VMware Workstation 6.5.2 on Ubuntu Linux, version 9.04.  I didn't know, at that time, whether some of my problems stemmed from having done an upgrade rather than a clean install of Ubuntu.  Now I found myself facing the same problem again, after a clean install of both Ubuntu 9.10 (Jaunty Jackalope) and VMware Workstation 7.

The problem was as follows:  if I checked the "Connect at power on" option, then audio would not run in the VM until (in full screen mode) I went into VM > Removable Devices > Sound Card > Connect; but when I did that, I would get this error message:

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

One recent discussion seemed to suggest that the problem was that Flash Player and/or Alsa audio.  I suspended my VMs and rebooted the computer.  When it rebooted, I made sure that Firefox was not running.  I resumed the VM and audio played OK in IrfanView.  I started Firefox inside the VM (i.e., in Windows XP) and played a YouTube video.  The audio was still OK in IrfanView.  I started a second session of Workstation and resumed a different VM in that session.  The manual sound card connection went OK; and there, too, I could play audio without stuttering.  The audio in the second VM was not as good; it had some static.

With those two VMs open, I started Firefox in Ubuntu (i.e., not in a WinXP VM).  I played another YouTube video.  Now I got an error message, and audio would not play in IrfanView within the VM.  I tried the other VM; same thing.  The error message was "Failed to open sound device /dev/audio: Device or resource busy.  Sound will be disconnected."  I went back to Ubuntu and killed Firefox.  Now I was able to connect the sound card and play audio inside the two VMs, same as before, complete with mini-stutters in the second one.  I started Firefox again in Ubuntu.  The audio was still OK inside the VM.  If I was playing audio in IrfanView in the VM and then went into a YouTube page in Firefox, the audio would not play in the latter.  I had to restart Firefox to get its YouTube audio to play, and then, as before, I was not able to hear audio inside the VM.  It worked the same way if I played a YouTube video in Opera rather than in Firefox.  So it seemed that the problem (which has apparently been around for years) continued to be within VMware Workstation.

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.

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

In a previous post, I described my efforts to get the sound working in a Windows XP virtual machine (VM) running in VMware Workstation 6.5.2 on Ubuntu 9.04. (Note that there are ways to use VMware virtualization for free.) I did not seem to have solved the problem, though it did appear that restarting the system (or perhaps shutting it down for a while and then restarting) would clear up the problem. In normal usage, for some months now, I had been able to play audio in more than one VM with little difficulty. It seemed that an update of VMware Tools may have screwed things up for me.

Hoping to reach a more efficient solution, I went to a discussion thread cited in a comment on that previous post. In that thread, someone advised typing "fuser /dev/dsp." Neither that nor "fuser /dev/audio" produced any results for me, however; I just got a blinking cursor in response.

I pursued another possibility mentioned in my previous post. Someone had suggested installing a second sound card in the computer. I had onboard audio on my motherboard, so in my case this would be the only sound card. Since it looked lonely, I decided to install another one as well. So now I had three physical sound output devices - the motherboard's onboard audio plus these two sound cards.

The next question was how to use them. When I went to Devices > Sound Card > Connect in VMware Player, inside my WinXP virtual machine, I just got the same old error message: "Failed to open sound device /dev/audio: Device or resource busy. Failed to connect virtual device sound." According to the post I was following, I should have been seeing separate devices: /dev/dsp and /dev/dsp1 (or something like that), etc. I wasn't sure where I was supposed to be seeing them. I went to Ubuntu's System > Administration > System Administration and skipped through that to the part that said, "Click the Test button to play a sound on the automatically detected playback device .... Do you hear a sound?" I didn't, so I clicked No and then Next. But it just took me on through other questions, so it wasn't actually going to help me solve the problem.

I went to System > Preferences > PulseAudio Preferences. (I had that option, I think, because I had gone through some PulseAudio stuff earlier, as described in my previous post.) But I did not see anything there that provided an obvious solution. I went to System > Preferences > Devices > Sound and experimented with the Sound Events - Sound Playback option. This one gave me an audible test sound only for the Autodetect, ALSA, and PulseAudio options. I left it on Autodetect. Autodetect also worked on the other options, so I left it as it was for them too.

A search for "sound cards listed" led me to a post where they seemed to confirm that System > Preferences > Sound was where I needed to be: clicking on Autodetect, they said, would show my sound cards. So, OK, looking at it that way, the longish list of sound options seemed to boil down to four software solutions (Autodetect, ALSA, OSS, and PulseAudio) and a mix of hardware solutions (HDA NVidia ALC883 digital and analog, ALSA and OSS; and ICEnsemble ICE1724, ALSA and OSS). I couldn't remember which motherboard I had installed in this particular computer, and I didn't know of a system information utility that would tell me that. (Sysinfo wouldn't.) I popped open the case and saw that the motherboard was a Gigabyte GA-M61P-S3. The manual for that motherboard indicated that its audio circuits used a Realtek ALC883 chip. So the ALC883 numbers in the list of sound options evidently referred to the motherboard. Since those weren't working, I tried plugging my headphones into one of the two newly added sound cards instead. I had been using the motherboard's green audio outlet, which in my understanding was the output, so that's the color of the outlet I used on the sound card as well. Back in Ubuntu's Sound Preferences dialog, I found that now I was getting no sound from any option. So apparently Ubuntu was not recognizing that sound card. I tried the green outlet on the second newly installed sound card. This, too, did not work on any option. I also tried the step that the post had advised, of connecting the motherboard's green out to the sound cards' blue in, but this too yielded no sound from the soundcards' green outlets. I looked up the ICEnsemble ICE1724 item mentioned above. This apparently indicated the VIA Envy24 chipset. I seemed to have installed a generic sound card that used that chipset. So that was evidently the one that Ubuntu recognized; but it wasn't helping me.

I started up VMware Workstation as root ("sudo vmware") with the intention of seeing what sound card options I had there. But the sound card settings option was greyed out for all of my VMs. I restored a VM, but its sound options were grayed out too. Same thing if I started up Workstation under my ordinary username. I had forgotten that, while it wasn't necessary to run Workstation as superuser (sudo) in order to adjust sound settings, it was necessary to power the VM down (not merely suspend it) in order to do so. I powered down a VM and, in Workstation, went to VM > Settings > Sound Card. There, I restored the "Use physical sound card" to its "Auto detect" option (since the /dev/audio thing wasn't working - see previous post) and deselected its "Connect at power on" option. I was thinking this would prevent the sound card error message at startup and would also keep VMs from grabbing the sound card if they didn't need it. I saved those settings and powered that VM back up in VMware Player. When it was powered up, I selected VM > Removable Devices > Sound Card > Connect. Now the audio in that VM was working. It wasn't working before, but now it was.

At this point, the solution seemed to be that "Auto detect" was just fine (i.e., I didn't need /dsp/audio or /dsp/dev1), but "Connect at power on" needed to be deselected, and I could only do that if the VM was either powered on or powered off (not suspended).

I tried with another VM whose sound wasn't working in VMware Player. Its settings weren't available in Player. Weird thing: it seemed like I was looking at it in Player one minute, and then - after I minimized it, I think - I was suddenly looking at it in Workstation. What happened to Player? To back up and check that out, I suspended that VM in Workstation, exited Workstation altogether, and opened that VM in Player. Trying again, I observed that its sound card was shown as connected (Devices > Sound Card) but it was not playing any audio. I suspended this VM in Player and, without closing Player, switched to another Ubuntu workspace (or, as they call it in Windows, another desktop). Then I went back to the previous workspace and, what do you know, Player was gone. I started a new session of VMware Player and, without opening any VMs, tried switching desktops again. But no, this time Player was persistent; it was still there when I returned to the original workspace. So I wasn't sure what that seemingly funky Player disappearance was about.

With Player open but with no VMs open, I started Workstation. I resumed the VM that I had just been using in Player, that had had no audio. Workstation said, "Cannot connect virtual device sound. No corresponding device is available on the host. Would you like an attempt to be made to connect this virtual device every time you power on the virtual machine?" I said yes, figuring that this would preserve the "Connect at power on" setting. This machine's sound card settings now said "Auto detect" and "Connect at power on," but not "Connected." I deselected the "Connect at power on" option and saved those settings. Then I suspended the VM in Workstation and resumed it in Player. I had to wait a few minutes for Workstation to finish suspending. When I tried too quickly, I got an error message:

This virtual machine appears to be in use.

If this virtual machine is already in use, press the "Cancel" button to avoid damaging it. If this virtual machine is not in use, press the "Take Ownership" button to obtain ownership of it."

But no, apparently that wasn't the problem, after all. The problem was that Workstation was still open and was showing that VM as suspended. I killed Workstation and tried again, and now Player opened the VM. Now I selected Devices > Sound Card > Connect and tried playing sound. No joy. That is, the sound still wasn't working. Instead of suspending it, this time I powered it down (Windows Start > Turn Off Computer > Turn Off). When the VM was off, Player vanished too. I started Player again, opened the VM again, and chose Devices > Sound Card > Connect, and then double-clicked on an audio (.wav) file. Still no audio. I switched to the Ubuntu desktop and double-clicked on the same audio file. It played in Ubuntu.

I suspended the VM. Player closed itself. In Workstation, I resumed both of these two VMs that I had been experimenting with. Oddly, this second one again said, "Cannot connect virtual device sound." But I had told it not to try at startup. Now I clicked on either Yes or No - I didn't write down which - and, as before, I got the message, "Virtual device sound will start disconnected." Its sound card settings were now set to "Auto detect" and neither "Connected" nor "Connect at power on" were checked. I suspended this VM. With Workstation still on and showing the first (audio working) VM but not this second one, I opened the second one in Player. I went to Devices > Sound Card > Connect. Still no sound.

I suspended the VM in Player and resumed it in Workstation. When I got that "Cannot connect virtual device sound" error message, I chose No. The sound card settings were the way I wanted (Auto detect, nothing selected). This time, instead of suspending, I powered it down in Workstation; and instead of using Player, I powered it up again in Workstation. (Workstation was what I had been using until recently; I wondered if maybe Player was part of the problem.) When it was up and running, it wouldn't play the .wav file. I changed its settings to "Connected." I got "Cannot connect virtual device sound."

The situation at present seemed to be that, unlike before, I would not be able to play sound in two different VMs without manually disconnecting the sound in one and connecting it in another. This was how I had understood it would be all along, but it had not actually been this way until now. To confirm this, I disconnected the sound card in the first VM and connected it in the second one. But no, when I went to save the change in the latter, I still got, "Cannot connect virtual device sound." I noticed that the first one was still set to "/dev/audio" rather than being back at "Auto detect." I powered down the first VM and changed that and then powered it back up. When the first one was completely powered down, by the way, the second one still would not play audio. Finally, with the first VM powered up and its sound card not connected, the second one powered up and connected, and both set to "Auto detect," I got that "Cannot connect virtual device sound" error when I tried to save the settings on the latter. With the first VM suspended, same thing.

I decided to start over. In Workstation, I powered off all VMs. I changed their sound card settings so that they were all the same. All were set to "Auto detect" and their "Connect at power on" option was unchecked. I shut down Workstation. In Player, I then powered on the one that had not been able to play audio. It still could not play audio. I powered on the other one. Now it could not play audio either.

In Workstation, I set the one that had been consistently nonworking back to the previous "/dev/audio" setting. I powered it on, set its sound card to "Connected," and tried to play audio. It worked. While it was still running, I repeated these steps with the VM that had previously been able to play audio. It could play audio too. In fact, they were both able to play the same .wav file at the same time, giving me a kind of funky reverb effect. I tried with a third VM. It went to "Auto detect" without a problem, but when I clicked "Connected" and then "Save," it gave me the "Cannot connect virtual device sound" message. I restarted that Windows VM and tried again. Same outcome. Likewise with a fourth VM. But the audio in the first two was still working. I powered down the third VM, changed it to "Connect at power on," and restarted it. I got the "Cannot connect" error message when it was booting, and again when I tried setting it as "Connected" once it had booted up. The first two VMs were still able to play sound. Movie Player in Ubuntu was also still able to play sound. I went back to the first VM and set it so that it was "Connected" and also was to "Connect at power on." I saved that configuration and rebooted it. It could still play audio after rebooting. I repeated those steps with several other VMs. Now they could all play audio.

I really have no idea what the fix was. It doesn't seem like any one step did the trick, and several steps seemed to work at one time or another. Restarting and/or rebooting was probably as good a fix as any, but it seemed to me that it, too, had failed to work sometimes. So I was back in business, confident that the same damn problem would crop up again in a day or two, just like before. Eventually, it occurred to me that maybe it was not a problem with VMs at all; maybe it was a problem with Workstation and/or Player, and it could only be fixed by restarting them or otherwise changing them on some basic level.  When it went wrong again, I decided it was time to update my previous posts on virtualization alternatives, including particularly the previous summer's look at VirtualBox. I have described the process of trying VirtualBox in another post.  Later, I came across this issue again with a later version of Ubuntu, and there I think I found the problem.

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.