[VMware] Ensoniq AudioPCI driver for Leopard v1.0.1

[Zenith432]

I'm using VMWare Workstation 7 and I've installed the Ensoniq Driver 1.02, but the audio output sound isn't very loud even at the highest volume.

I've figured out the reason for this, and uploaded an interim release to solve this problem.

 

Version number 1.0.3d1. Installer is found with the VMsvga2 files on sourceforge under Audio (see link in Post#1 in this thread). Works for both Leopard and SnowLeopard.

 

Release Notes

• Increased output volume by 12db.
  
• Vectorized floating point loops to use MMX/SSE/SSE2 (available since the P4, and required by Apple's kernel anyhow.)
  
• Improved cache coherency on the DMA output buffer.
  

 

Version 1.0.3 is still "in development", and there are some more things I plan to do with it before releasing it. This interim version is due to the low volume problem being important enough to resolve ASAP.

 

When installing, choose the "Install the Full AppleAC97Audio.kext" to get the volume fix. This is the default install option. If you choose to install the EnsoniqAudioPCI.kext PlugIn on your own AppleAC97Audio.kext provided by someone else, you won't get any difference from v1.0.2.

 

Please post if you encounter problems with this version. Note that the stuttering issue hasn't been fully resolved yet.

 

I've updated the uninstallation script (uninstall.sh) to account for this new installation package.

 

May be a stupid question, but is it possible to use the driver in regular boot, i.e. without VM Ware?

You can use Apple's AC97 chip drivers for other chipsets (Intel, AMD, VIA, AD) with this version of AppleAC97Audio.kext outside a virtual machine. As for using it outside a VM with a hardware ES137x chipset - I'm not sure. In principle the driver should work, but VMware's emulation has some limitation that I added a workaround for. This workaround might cause the driver to fail with a hardware ES137x. If you have one, go ahead and try it. It may work anyhow.

[Zenith432]

I'm using VMWare Workstation 7 and I've installed the Ensoniq Driver 1.02, but the audio output sound isn't very loud even at the highest volume.

I've discovered another way to resolve the low volume issue that works with Ensoniq 1.02. Add the following line to the VMX file

pciSound.emulateMixer = "FALSE"

This will make the guest use the maximum volume for the mixer output instead of emulating a mixer, and you'll get 12db higher output.

Another setting I found is

pciSound.enableVolumeControl = "FALSE"

which disables the volume control on the guest completely. You'll always get the maximum volume on the guest side, but you can still control the volume from the host.

 

In another bit of "good news", I figured out the cause for the stuttering audio It's got to do with the way VMware emulates the ES137x, which makes it incompatible with Apple's audio architecture. Apple's audio architecture assumes that the sound card drains the output DMA buffer at a fairly fixed rate, which could fluctuate somewhat around the sample rate, but not too sharply. VMware's backend doesn't really "drain" the output buffer, but instead picks up the whole thing with "memcpy", and then passes it on to the host sound system from another DMA buffer which it prepares on the host side. VMware's emulation is technically permissible, but doesn't resemble anything like a real audio card. It works for Linux & Windows, because those OS's don't make any assumptions about the drain rate of the DMA buffer.

I'm trying to devise a workaround for this that doesn't require redesiging the whole driver. If it turns out that solving this requires a complete redesign I may drop it.

BTW, I think this issue would exist even if VMware emulated another chipset, but continued to drain the buffer the way they do. It's not specific to the ES137x.

[Nemes]

I've discovered another way to resolve the low volume issue that works with Ensoniq 1.02. Add the following line to the VMX file

pciSound.emulateMixer = "FALSE"

This will make the guest use the maximum volume for the mixer output instead of emulating a mixer, and you'll get 12db higher output.

Another setting I found is

pciSound.enableVolumeControl = "FALSE"

which disables the volume control on the guest completely. You'll always get the maximum volume on the guest side, but you can still control the volume from the host.

 

In another bit of "good news", I figured out the cause for the stuttering audio It's got to do with the way VMware emulates the ES137x, which makes it incompatible with Apple's audio architecture. Apple's audio architecture assumes that the sound card drains the output DMA buffer at a fairly fixed rate, which could fluctuate somewhat around the sample rate, but not too sharply. VMware's backend doesn't really "drain" the output buffer, but instead picks up the whole thing with "memcpy", and then passes it on to the host sound system from another DMA buffer which it prepares on the host side. VMware's emulation is technically permissible, but doesn't resemble anything like a real audio card. It works for Linux & Windows, because those OS's don't make any assumptions about the drain rate of the DMA buffer.

I'm trying to devise a workaround for this that doesn't require redesiging the whole driver. If it turns out that solving this requires a complete redesign I may drop it.

BTW, I think this issue would exist even if VMware emulated another chipset, but continued to drain the buffer the way they do. It's not specific to the ES137x.

Very interesting. I've always assumed VMWare was going about audio emulation in a tweakier than it seems fashion, and this seems to back that assertion.

 

Thanks for the update Zenith, and thanks for the hard work.

[Zenith432]

I've finalized EnsoniqAudioPCI v1.0.3 and uploaded an installer to sourceforge.

 

This version is very similar to pre-release v1.0.3d1. I've left installers for all previous versions under the Archive sub-folder in case someone experiences a regression in playback with v1.0.3.

 

There is a "Release Notes" file in the same place.

 

The un-installation script in the top-level folder can remove the audio driver as well as the SVGA & Mouse drivers.

 

I've given up on solving the stuttering audio problem at the driver level. The glitches are due to a race condition between producer and consumer on the output DMA buffer.

• The producer is a CoreAudio thread in the guest charged with generating audio output samples for the buffer. The guest thread uses a self-timing scheme to try and generate samples in time.
  
• The consumer is a VMware backend thread on the host that emulates the ES1371 chipset. This thread partitions the DMA buffer into chunks, copying and feeding the chunks to the host sound system. The host thread uses a different self-timing scheme to insert delays between chunks. The host timing scheme is affected by a VMX parameter called "pciSound.playBuffer". This parameter is an integer measured in milliseconds (default value is 200), and the host thread attempts to simulate a virtual buffer whose size (measured in milliseconds) is the given value.
  
• The only flow-control between producer and consumer is a weak flow-control where the producer takes timestamps of DMA buffer wrap-arounds, and calculates a long-term average of the consumer's drain rate. Note that due to the self-timing scheme in the host thread, the timing of the buffer chunks in the consumer are somewhat erratic, and occasionally deviate sharply from the average rate.
  

I tried various buffer schemes to counter the race condition -- attempting to give the producer enough advance processing time to keep it ahead of the consumer, but it always falls behind. The best I was able to do was get 30-40 seconds of glitch-free playback, only to have the glitches lump together to form a second or two of very audible disruption in playback. This was only on OS 10.6, as on OS 10.5 I was never able to get glitch-free playback for any extended period of time.

 

This race condition can't be solved at the driver level. In order to correct, it's necessary to either

• rewrite the consumer (host) code to be event-driven based on feedback from the host sound system instead of using a self-timing scheme. This way the emulation would more closely resemble the buffer drain of a hardware ES1371 chip-set.
  
• re-engineer the CoreAudio architecture to be interrupt-driven instead of using a self-timing scheme so that the producer generates audio samples on-demand as the consumer reports its buffer progress using guest interrupts.
  

There is a similar issue with the input DMA buffer as well -- if you try record sound from a microphone in the guest, you'll get a lot of echo and glitches in the resulting waveform.

[Poopy]

I am actually having pretty good success with the latest (1.0.3) driver in my setup. The one setting that makes

all the difference in the world is:

 

pciSound.DAC2InterruptsPerSec = "1024"

 

You will probably need to tune that value according to your system's speed and the amount of load in the VMWare session. There is definitely a sweet spot for that value. Values too low or too high will result in stuttering and/or audio dropouts. I find that even values as low as 8 work fine when the session is idle but there is a lot of stuttering under even the slightest load. Values ridiculously high (like 65536) also result in stuttering. Without specifying this setting, audio is horrible.

 

In my system, values between 64 and 1024 seem to work very well.

 

As a load stress test, I ran "yes > /dev/null" in 9 different windows along with iTunes streaming an internet radio station. top shows a load average of about 9.6 with about 100% CPU usage. There are no audio glitches at all. This may not be the best way to test the system under load. The CPU load will definitely affect interrupt latency so this is a fairly rigorous test case. But I haven't added other interrupt sources. Perhaps a better test case would be running apps that generate a lot of interrupts that are unrelated to audio. But for now I am happy with my audio.

 

The other settings mentioned in this thread have no effect in my setup. I am not using any of these:

sound.highPriority = "TRUE"

pciSound.priorityBoost = "TRUE"

pciSoundDAC1InterruptsPerSec = 0

pciSound.emulateMixer = "FALSE"

 

Thank you, Zenith432, for all your fantastic work!!!!!!

[vampirnata]

I am actually having pretty good success with the latest (1.0.3) driver in my setup. The one setting that makes

all the difference in the world is:

 

pciSound.DAC2InterruptsPerSec = "1024"

 

You will probably need to tune that value according to your system's speed and the amount of load in the VMWare session. There is definitely a sweet spot for that value. Values too low or too high will result in stuttering and/or audio dropouts. I find that even values as low as 8 work fine when the session is idle but there is a lot of stuttering under even the slightest load. Values ridiculously high (like 65536) also result in stuttering. Without specifying this setting, audio is horrible.

 

In my system, values between 64 and 1024 seem to work very well.

 

As a load stress test, I ran "yes > /dev/null" in 9 different windows along with iTunes streaming an internet radio station. top shows a load average of about 9.6 with about 100% CPU usage. There are no audio glitches at all. This may not be the best way to test the system under load. The CPU load will definitely affect interrupt latency so this is a fairly rigorous test case. But I haven't added other interrupt sources. Perhaps a better test case would be running apps that generate a lot of interrupts that are unrelated to audio. But for now I am happy with my audio.

 

The other settings mentioned in this thread have no effect in my setup. I am not using any of these:

sound.highPriority = "TRUE"

pciSound.priorityBoost = "TRUE"

pciSoundDAC1InterruptsPerSec = 0

pciSound.emulateMixer = "FALSE"

 

Thank you, Zenith432, for all your fantastic work!!!!!!

 

Great to hear this, could you please let me know where you set these options?

 

Thank you Zenith

[Donk]

Great to hear this, could you please let me know where you set these options?

 

Thank you Zenith

 

You can add them to the VMX file of the guest you are using.

[Ridicule]

Thanks for the driver Zenith, sound is smooth, just having one problem..

 

There's a delay of around 200-500 ms from the sound coming from the guest to the host. Is this due to the mentioned buffering of the output stream? In that case I guess there's nothing which can be done.

 

I'm using the latest 1.0.3 driver, VMware ws 7.1.3, i7 950 - Win 7

[Zenith432]

There's a delay of around 200-500 ms from the sound coming from the guest to the host. Is this due to the mentioned buffering of the output stream? In that case I guess there's nothing which can be done.

Try setting a lower value for "pciSound.playBuffer". The default is 200 [see my discussion of this earlier].

When playback starts, the VMware audio thread takes off like a rocket in order to fill a 200-millisecond buffer as quickly as possible. The CoreAudio thread in the guest falls behind big-time, detects this and does some kind of internal reset, which causes the noticeable lag.

VMware's code assumes that the guest will fill new sample buffer chunks on-demand as it delivers interrupts. Other OS's do this. CoreAudio doesn't. Instead, it measures a long-term average of the playback sample rate, and uses it to pace itself. When it starts out, CoreAudio uses the formal sample-rate (44100 or 48000). From the guest's viewpoint, VMware's code does have a long-term "stable" rate, but in the short term the rate is bursty and un-even, and this leads to CoreAudio falling behind and doing adjustments to catch up.

 

BTW, The Windows backend has a maximum of 256 for pciSound.DAC2InterruptPerSec. If you set any higher than that it uses the value 44.

[jmacie]

Wow, Thank you Zenith432, It's amazing and wonderful what you've done with the video and audio kexts! Along with Mac Son of Knife, Donk, and Albert, you've made the vm very, very operational. I'm finally able to not have to reboot to hackintosh just to try something on mac! I couldn't follow(implement,understand) the different tweaks for ensonicaudiopci, as I was experiencing choppiness. So after reading and googling for others tweaks, like http://blog.mezo.com/?p=628, I decided that somehow, someday, you would get this perfected. Anyway, I lowered my guest vm cpu core(s) down, as I use Q9450. I now have GREAT audio! So thanks again! I now love my vm! johnm

[eelm]

Hi there,

First of all thanks to all for the work done here and there. Got a new laptop (HP DV7-6150eb) for my wife and managed to get Leo 10.6.3 running in a vmware wkst 8 and this made me save quite some money because she wanted a mac that I couldn't afford. However I still have an issue with the sound and I hope you will be able to point me to the right direction because sounds like I have missed something.

I have downloaded and installed the EnsoniqAudioPCI_v1.0.3_Common_Installer.pkg , I have double checked the sound in the vm settings and it is connected and I have added the above mentionned lines in the vmx file but strangely I have no sound. When I go in the sound properties in Leopard, I have no input or output device. I have also installed the vmware tools with the darwin.iso that I got from the unlocker.

Was wondering, does this has to be done in a specific order ? I might have not connected the sound during the setup of Leopard (would it be the cause ,) or I have simply forgotten a step ?

 

Tkx

 

Eelm

[Zenith432]

Try setting

sound.virtualDev = "es1371"

in your VMX file.

[james3]

Hi there and first of all thanks for your job

I'm running MAC OSX 10.8.2 VMware Workstation into a Linux Mint 14 Mate 64-bit machine, I installed your audio driver but I have no audio at all. Is there any fix for this ?

 

here are some specs

 

Linux 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Audio: Card: Intel 7 Series/C210 Series Chipset Family High Definition Audio Controller driver: snd_hda_intel

Sound: Advanced Linux Sound Architecture ver: 1.0.25

HDA Intel PCH Realtek ALC663

[Zenith432]

Is there any fix for this ?

Well, hello, VMware have supported HDA for quite a while now and I've stopped development or support of EnsoniqAudioPCI.

• Set sound.virtualDev = "hdaudio" in VMX file.
  
• Works with AppleHDA.kext since OS 10.7.
  
• You can remove EnsoniqAudioPCI.kext.
  

[james3]

Hello my sound.virtualDev was already set = "hdaudio"

 

I didn't understood if there is a possibility to enable sound in my MAC OSX 10.8.2 guest Virtual Machine or no

 

Do I have to install AppleHDA.kext ??

 

What should I do to enable it if it's possibile ?

 

thanks