Audio stuttering on VMware Workstation with multiple cores/cpus

[Tmgenesys]

Hi All,

We are experiencing a problem with audio on our environment.  When running on VMware Workstation (we've tried on both Workstation 7.x and newly releaed 8 -- hardware version 7), if our machine has multiple cores (or multiple cpus), several audio applications have serious problems with stuttering audio during playback.  When changing back to 1 CPU, 1 core the audio is fine.  Specifically, this happens with Goldwave audio editor and X-Lite/Eyebeam/Bria SIP softphones from Counterpath. Playing the audio with something like Windows Media player seems to work fine.  Running the apps on native hardware with dual/quad core is just fine -- it's when they are run in a VM that there is a problem.

Sticking with 1 CPU 1 core is not a good solution as it has the effect of slowing down the processing other applications on the machine by 30-40% relative to having dual core.  This is an environment used by 400+ users and the audio is an important part of the environment as it is used in sales demonstration process for our organization.

We are currently using 64bit Windows 7 Enterprise as host (8GB of RAM), and Windows Server 2008 R2 64-bit as the guest (6GB RAM allocated to guest VM).  This is on i7-quad core mobile processors and solid state drives with virtualization extensions turned on, so there is plenty of horsepower.

We have made the tweaks appropriate to Windows Server 2008 to provide for better quality audio (per http://www.win2008workstation.com/win2008/enable-sound-acceleration) in the Server OS.

We saw similar issues in our previous Windows Server 2003 32 bit environment with the default VMware audio driver.  We worked around this by forcing a Creative Soundbalster PCI 128 driver into the environment and the problem largely disappeared.  Unfortunately, in our 64 bit environment, there doesn't seem to be any alternative drivers for audio -- and no 64-bit drivers from creative for ES1371 or open source drivers for that environment either.

We've tried setting the device to be 'SB16' via sound.virtualdev=SB16 (per http://sanbarrow.com/vmx/vmx-sound.html), however, it didn't seem that Workstation 7/8 pays attention to that as device was exact same in Device Manager.  We've tried various combinations of the other options listed (playing with sound.maxlength and sound.smallbaclksize) without success.  We've tried running the apps with single-processor affinity and real-time priority -- no difference.

Ultimately, we're thinking this is a VMware audio driver problem on multi-core/CPU and since there are no alternative audio drivers out there, we're at a bit of a dead-end.  We've spent many hours searching forums and trying different things, but to no avail.

Anyone have any ideas?  We're stuck and would like to use our lifeline and phone-a-friend here (preferably to the audio driver engineer on Workstation ).  Dirver alternatives in 64-bit?  VMX tweaks?  Application tweaks?

Thanks all for any ideas/assitance you can provide --

Brad

[continuum]

I would highly recommend NOT to use the virtual VMware-sound card at all and instead use an external USB-audio device.

That should give significantly better results.

If possible stick to a single virtual CPU

[Tmgenesys]

Thanks for the quick repsonse.

As expected (we've tested this previously), using USB connected inside the guest VM works just fine;  no stuttering at all.  Using USB on the host and passing through audio via default VMware driver to the host results in the same stuttering on the USB devices as the default sound card.  This seems to point to VMware driver as being the culprit.

Unforunately, we don't have the ability to mandate USB audio devices / speakers for the users of the image so we are really looking for a way to fix the issue via the means within the Workstation application.

Any other ideas out there in VM land?

Thanks,

Brad

[jschellhaass]

I had a similar problem with win 7 x64.  I ended up changing the hardware version back to version 7 from 8.  This caused the sound card to switch from an HDA device to a vmware sound adapter.  It seems to have eliminated the stutter issue I was having.

[BCGen]

An update on this isue;  We had previously tried on Workstation 8 (though using hardware version 7).  Upgrading to virtual hardware 8 on WS 8 seems to solve the issue.  Now, just a matter of getting everyone upgraded to the latest and greatest.

We suspect there is a driver issue with hardware 7 version when dealing with multi-core/CPU  environments.  At this point, however, we'll just be moving forward with WS8...

[MrDuggan]

I had this same issue with a Windows XP 32bit guest.

I had upgraded my virtual hardware and tools to version 8 and it did not help.

I then created a fresh Windows XP install as version 8, to rule out the upgrade, same issue.

Soundcard was Realtek HD onboard audio on a Dell XPS 8300.

Uninstalled ws8, re-installed ws 7.1.4 and no audio problem with original non-upgraded images.

[milo8080]

hello,

I'm on windows 7 x64, and vmware workstation 8.0 and i have the same sound choppy problem. (in workstation 7.x this not happens).

can u please explain how to fix this?

i mean: are you using an external usb audio device or the internal card via usb?

i don't get it.

tnx

[BCGen]

By upgrading the ‘Virtual Hardware’ version of the underlying image to 8, the problem was solved for us.

[richardlan212]

i found vmware can only work right with the original cores.

if you have a 4 cores / 8 threads i7 CPU, i suggest you to set 4 cores to your VM.

i have an i3 laptop with 2 cores / 4 threads, if i specify 4 cores to my VM, the audio must be stuttering. with 2 cores, everything is ok.

[admin]

Have the same issue and resolved by changing the default format 16bit 44100 Hz (CD Quality) to 24 bit 44100 Hz (Studio Quality).

Go to Speaker Properties in Windows 7, Advanced, Change the default format from 16bit 44100 Hz (CD Quality) to 24 bit 44100 Hz (Studio Quality) and test. It is

Other notes:

The HW version 8 that comes with Workstation 8 has new HDAudio compatible with the RealTek ALC888 7.1 Channel High Definition Audio Codec.

I have the same issue with Windows 7 if i use HW8.

There is no issue with HW7 because it uses PCI audio.

Alternatively you can change the HDAudio in HW8 to PCI KB Article: 2010400

sound.virtualDev = "hdaudio"

Change this entry to:

sound.virtualDev = "es1371"

But the interresting is that if you change the Speakers setup on the HDAudio in Windows 7 from Stereo to any other type like Quadrophonic, Surround and Test it the sound is not distorted. That brought me to the idea of changing the default format 16bit 44100 Hz (CD Quality) to 24 bit 44100 Hz (Studio Quality).

[DrHow]

I was experiencing very garbled audio with an XP guest on a Windows 8.1 machine with a 4-core AMD A10-5700 APU.  I had specified my guest machine with 2 cores.  Based on this thread I decided to try changing that.  With 1-core, it was still bad.  But with 4 cores, it is OK.  There are still minor glitches; but I don't need for it to be good - just understandable.

[globalist007]

Sorry to resurrect this old issue, but I only have a selection of multiple 16bit options, not a single 24bit one. Any ideas?

[TonyValenti]

Hi All,

I've run into this same issue and I wanted to post a solution that worked great for me.

1.  Completely uninstall VMWare Tools

2.  Do a custom Reinstall with the minimum number of VMWare tools necessary, specifically, DO NOT install the audio driver.

I found that as soon as I installed the VMWare audio driver, I'd have audio issues.

[TimothyHuckabay]

As of Workstation 14.x, this continues to be a major issue if the USB sound card is attached to the virtual machine rather than the host.  It does not seem to matter how many cores, whether physical or physical and virtual, the VM is configured to use.  However, if the external USB sound card is instead left connected to the Host system, then VMware will actually pass the audio from the guest to the host and the microphone from the host to the guest, so that both audio playback and audio recording function normally; in this case, both the Playback and Recording devices (e.g., under the Sound settings of Windows 10) will enumerate as "High Definition Audio Device"—exactly the same as if you were just using the host's own speakers and microphone without the external USB sound card.  I was surprised to discover this, as I have yet to see any documentation from VMware whatsoever that addresses such pass-through for USB sound cards.

The apparent solution, therefore, is to completely avoid connecting the external USB sound card to the virtual machine.  Doing otherwise results in non-functional output audio, even if microphones continue to function normally.  Notably as well, controls on the Host (e.g., AGC or Automatic Gain Control on the Custom tab, and the level setting on the Levels tab, of Windows 10's Recording settings) are functional when the USB sound card is connected to the Host rather than the Guest.

When the external USB sound card is connected to the Host:

For audio playback, volume should be at 100 percent inside the virtual machine, with actual volume controlled from the Host; likewise, Enhancements, Spatial sound, and Default Format under Advanced, in Windows for example, should be set on the Host.

For recording within the virtual machine, note that the Levels settings on the host and within the VM are both functional, but Microphone Boost inside the virtual machine is non-functional, as gain must apparently be set on the host only by using, for example, AGC.

[STem1980]

As for XP/2000/NT, this issue has been there for quite a while. It basically has to do with dynamic system timer control in modern host OSes, sound becomes garbled when system timer resolution is set to the maximum value - seemingly it is done to conserve power. Anything that sets the system timer resolution to a high enough value - be it Chrome playing a Youtube video or WMP in any guest fixes sound output.

BTW, VirtualBox seems to be forcing system timer resolution to 1 ms which helps avoid this problem.

I've developed a utility to fix this issue, it's available at GitHub - temerkhanov/SetTimerService It's a Windows service which sets system timer resolution inside a guest OS so that it is enough for the guest sound subsystem to function properly. Installation is simple: just copy the binary to any directory, run "SetTimerService /install" from there (admin privileges are necessary), the service will register itself to start automatically and will set timer resolution at startup to 2 ms by default (it can be controlled via a registry variable "HKLM\SYSTEM\CurrentControlSet\Services\SetTimer\Parameters\TimerResolution" in 100 ns units, but the actual resolution is more coarse-grained). XP and 2003 may also need running the install_xp.cmd script which makes this service start before the audio subsystem.

[anion21]

I had the same issue for a long time and meanwhile I think it is a resource-bottleneck-issue. I could solve it in many cases by updating the RAM:

I had 16GB RAM on my host-machine and I assigned 4GB to the VM. Host- and guest-machine have Windows 10 installed. The audio-quality was very bad due to the stuttering. I gave up trying to solve this problem.

Last week i updated the RAM of my host-machine to 64GB. (I did'nt updated it to solve the stuttering-problem, I need it anyway on the host-machine). And I have also increased the RAM of the VM to 8GB to increase its performance. And now i noticed randomly: The audio-quality is better. Now in many cases i do not have any stuttering anymore.

But now I still have stuttering when

- the CPU-usage is very high or

- I am hearing music from a local file for example and have any application running which "steals" the disk-I/O-bandwidth

[Digicoma]

Lifesaver!  Thank you!  You and your efforts have solved the problem!!!

[RitterVonNi]

This (referring to @TimothyHuckabay 's post)

This has solved all my issues. I spent hours fiddling around with the settings, changing vmx variables (not so easy on encrypted VMs) and in the end, instead of passing through USB devices as I thought I had to, I just let VMWare use my Hosts' defaults.

I think this has saved me some more grey hair - thank you!