The return of the infamous /dev/dsp bug

[jdb2]

Hello. I use VMware Workstation 6.5 version "6.5.2 build-156735" on Kubuntu Linux. Ever since Kubuntu 8.04 I have been unable to get the virtual sound device working in a Windows XP guest -- VMware would complain about insufficient permissions on /dev/dsp. Well, I've upgraded my OS to Kubuntu 9.04 Jaunty Beta 1 and the same problem is back in a slightly different form : Now when I attempt to resume or power-on the guest I get the following messages : "Failed to open sound device /dev/dsp1: Invalid argument" and "Virtual device sound will start disconnected."

Does anyone have a clue about how to solve the above? I've done some searching, but all I could find was the same question, unanswered. You would think VMware would have given this bug a high priority by now.

Any help would be appreciated,

Regards,

jdb2

[frenchrh]

I've got the same issue, running VMware Wrksta 6.5.2, on OpenSuse 11.1 32bit, and using a WinXP vm. I get the same sound can't connect to dev/dsp or dev/dsp1.

What is the solution or workaround?

[jdb2]

I enabled "Settings->Options->Advanced->Gather debugging information: full" and "Settings->Options->Advanced->Log virtual machine progress periodically." After powering on the VM I grepped vmware.log for 'sound' .

Here are the results :

 
Apr 12 22:46:42.817: vmx| DICT           tag.soundConfig = devices_sound.htm
Apr 12 22:46:42.818: vmx| DICT             sound.present = TRUE
Apr 12 22:46:42.818: vmx| DICT            sound.fileName = -1
Apr 12 22:46:42.818: vmx| DICT          sound.autodetect = TRUE
Apr 12 22:46:42.818: vmx| DICT       sound.pciSlotNumber = 33
Apr 12 22:46:42.819: vmx| DICT           tag.soundConfig = devices_sound.htm
Apr 12 22:46:57.289: vcpu-0| [http://msg.pciSound.DspOpenFailed|http://msg.pciSound.DspOpenFailed] Failed to open sound device /dev/dsp1: Invalid argument
Apr 12 22:46:57.289: vcpu-0| [http://msg.device.startdisconnected|http://msg.device.startdisconnected] Virtual device sound will start disconnected.

Maybe someone more knowledgeable about VMware internals can make some sense of this.

Regards,

jdb2

[jdb2]

I found a partial solution here : . The only problem is that the host and guest can't access /dev/dsp at the same time, so you can't have, say, a CD playing in the background on the host while you're playing eg. a flash shoot-em-up game on the guest and get a mixture of audio out of your sound card from both sources. From what I've seen ( or heard ) it looks like the host takes precedence.

jdb2

[jsa]

I found a partial solution here : . The only problem is that the host and guest can't access /dev/dsp at the same time, so you can't have, say, a CD playing in the background on the host while you're playing eg. a flash shoot-em-up game on the guest and get a mixture of audio out of your sound card from both sources. From what I've seen ( or heard ) it looks like the host takes precedence.

jdb2

I don't quite understand why the VM would be accessing the host's hardware. I thought that was all virtualized, and the vmware running in the host merely handed sound from the guest off to the host os.

[jdb2]

I found a partial solution here : . The only problem is that the host and guest can't access /dev/dsp at the same time, so you can't have, say, a CD playing in the background on the host while you're playing eg. a flash shoot-em-up game on the guest and get a mixture of audio out of your sound card from both sources. From what I've seen ( or heard ) it looks like the host takes precedence.

jdb2

I don't quite understand why the VM would be accessing the host's hardware. I thought that was all virtualized, and the vmware running in the host merely handed sound from the guest off to the host os.

When I said "guest" I of course meant the guest's virtual machine. From the guest VM's OS's point of view it thinks it's accessing a physical sound card.

jdb2

[jsa]

Sure, I understood that much.

But the guest OS looking at /dev/dsp is really pointing to a virtual device created for its benefit by Vmware Workstation.

Its not looking at THE REAL /dev/dsp of the host.

This virtual /dev/dsp gets routed whereever vmware workstation sends it based on the config file for that VM.

So I'm just as confused as ever. ?:|

[jdb2]

Sure, I understood that much.

But the guest OS looking at /dev/dsp is really pointing to a virtual device created for its benefit by Vmware Workstation.

Its not looking at THE REAL /dev/dsp of the host.

This virtual /dev/dsp gets routed whereever vmware workstation sends it based on the config file for that VM.

So I'm just as confused as ever. ?:|

I neither stated nor implied any such idea. The guest OS is *encapsulated within a VMware virtual machine* -- *it does not and cannot directly access the host machine's hardware;* it is isolated from the host machine's hardware and software by the VM and is consequently oblivious to their existence.

jdb2

[Ack032964]

After trying everything for 4 hours i stumjbled on a fix for me .. I sure hope it helps

once in your guest open vmware tools, goto DEVICES, AND SIMPLY TICK "Audio"

WOOOWW, it works!!

[Ack032964]

After 4-5 hours of frustration and trying everthing google threw at me , I stumbled on a fix for me.

Simply once in the guest, open VMware Tools, click on Devices, and tick off "Audio" !!!!!

ande BAMMMM IT WORKS

[holopoj]

The problem for me turned out to be that when you click the power on button it makes a little 'boomp' sound, and playing that sound caused vmware to not be able to access the sound card. The setting for this is actually in the gnome settings, not the KDE settings, even on kubuntu. These steps resolved the sound problem for me:

1. Go to a terminal (or hit alt-F2) and run: gnome-control-center

2. Under the Hardware section there is a Sound icon, click that. Click the Sounds tab and uncheck "Play alerts and sound effects".

I can play sound in either the host or the guest while the VM is running, just not at the exact same time.

[jdb2]

The problem for me turned out to be that when you click the power on button it makes a little 'boomp' sound, and playing that sound caused vmware to not be able to access the sound card. The setting for this is actually in the gnome settings, not the KDE settings, even on kubuntu. These steps resolved the sound problem for me:

1. Go to a terminal (or hit alt-F2) and run: gnome-control-center

2. Under the Hardware section there is a Sound icon, click that. Click the Sounds tab and uncheck "Play alerts and sound effects".

I can play sound in either the host or the guest while the VM is running, just not at the exact same time.

Unfortunately for me, everything under the sounds tab is greyed out.

jdb2