64 replies to this topic

[den007]

... ES137x audio driver. It can be used for sound support when running OS X Leopard as a VMware guest...

May be a stupid question, but is it possible to use the driver in regular boot, i.e. without VM Ware? I loaded kexsts, but no sound card shows up in my SL. No errors on console either.

[Fask]

After much trial & error, I've figured out the reason for the choppy audio, and came up with a solution which appears to work. I've uploaded the new version and attached to the original post.

1. Bumped version number for EnsoniqAudioPCI.kext from 1.0.0 to 1.0.1.
2. Remove the old kext and install this one in its place.
3. Remove any setting of "pciSound.DAC2InterruptsPerSec" from your vmx file.



I've also modified AppleAC97Audio.kext so that it can drive the chip at a 44.1KHz sample rate. Previously it was limited to driving the chip at 48KHz. This isn't critical, since both sample rates appear to work just fine. You can still use EnsoniqAudioPCI.kext with an existing AppleAC97Audio.kext.

How do I uninstall EnsoniqAudioPCI.kext 1.0?

[MSoK]

How do I uninstall EnsoniqAudioPCI.kext 1.0?

On Zenith432's site there is an uninstall.sh file which is an uninstall script for both the Audio and Graphics drivers, which lets you select what to uninstall, for example EnsoniqAudioPCI, link below:

http://sourceforge.n.../vmsvga2/files/

[robr]

Hi to everybody, I have installed Ensoniq AudioPCI driver ver. 1.02 and in vmware 7.0 the audio goes jerky and is disturbed, it suits me to install the version 1.01? Thanks

Same problem here. The system sounds (real short dings and what not) work fine with it, but when I try to play the Garageband guitar tutorial, it's horrible. Someone in the office asked if I had a cappuccino machine running over here.

I'm running OSX SL 10.6.2 in VMware 7 on a Dell XPS M1530 laptop with a Core2Duo T9300 processor.

[MSoK]

Same problem here. The system sounds (real short dings and what not) work fine with it, but when I try to play the Garageband guitar tutorial, it's horrible. Someone in the office asked if I had a cappuccino machine running over here.

I'm running OSX SL 10.6.2 in VMware 7 on a Dell XPS M1530 laptop with a Core2Duo T9300 processor.

The only thing I have found makes any difference is to change the Format between 44100.0 Hz and 48000.0 Hz under Audio Devices (VMAUDIO).

[LordKitsuna]

hey im kinda new to this. i just installed it and i have sound now but its really skippy where can i find the vmx file that everyone is talking about so i can change those settings to see if they help? or perhaps something else i can try

[Donk]

hey im kinda new to this. i just installed it and i have sound now but its really skippy where can i find the vmx file that everyone is talking about so i can change those settings to see if they help? or perhaps something else i can try

There isn't anything in the VMX to help. You can try the previous post idea of changing the settings inside Mac OS X, but don't expect miracles.

[drbold]

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 heard other people having this issue. I'm very happy that the audio works extremely well, except for this one issue. Anyone know of a fix for this? Does one even exist?

[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 heard other people having this issue. I'm very happy that the audio works extremely well, except for this one issue. Anyone know of a fix for this? Does one even exist?

I've noticed this too on Windows 7 host. Couldn't find any way to fix it. The only thing to do is increase the volume on the host and/or speakers.
On the guest side, the ES137x chipset has two different volume controls - a legacy one and an AC97 one. OS X uses the AC97 control to change the volume. I tried tweaking the legacy volume control to see if makes any difference, but it doesn't. Looks like both volume controls are actually just one control with two access paths.

Just to recap, I was never able to find the reason for the choppy audio that happens on some systems, so that issue isn't solved either. I added lots of parameters to tune every possible setting in Apple's IOAudioFamily & CoreAudio, but none of that solved the problem. So I never released a version of EnsoniqAudioPCI with these additional parameters.

On a positive note, back in September 2010, VMware signed up for getting a few new PCI device IDs, some for emulating a SoundMAX HDA chipset. If they ever get around to releasing an HDA chipset emulation, it may perform better than the ES137x emulation. So there's hope yet.

[dudestatus]

I have noticed that audio performance seems to be correlated with hd use. I was playing an mp3 in itunes on driver 1.0.2 and the sound was completely fine until I performed a copy of a large image file, wherein it became horribly choppy and rough. The audio returned back to normal after I canceled the copy.

[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