64 replies to this topic

[Zenith432]

aronx, on Sep 4 2009, 06:32 PM, said:

Thanks for the quick reply. Yes, I'd (and maybe others too) like to hear the long answer.

IOAudioEngine expects the chip driver to maintain a DMA ring buffer from which samples are fed to the playback channel.  The driver today uses a 128KB buffer, which is enough for about 680 milliseconds using a 48KHz sample rate.  The chip driver is expected to provide the following functions

• report an interrupt every time the buffer wraps around.
  
• report an accurate position of the DMA transfer pointer whenever IOAudioEngine asks for it.

IOAudioEngine maintains a software "erase head".  It sets up a timer to trigger 4 times per buffer at regular intervals.  The timer routine asks the chip driver for the position of the DMA pointer.  It then runs an "erase head" that erases the buffer from the position of the last erasure to the current position of the DMA pointer.  "Erasure" here means that it marks the part of the buffer that's already been played as empty, and also erases that part of the buffer to zero.  The reason it needs to erase the buffer to zero is because IOAudioEngine supports software mixing - multiple user-clients can be active at the same time and come in and add their samples to the buffer.
IOAudioEngine reports three parameters to the user-clients via shared memory

• The number of times the buffer has wrapped around since playback started.
  
• A timestamp of the last time the buffer wrapped around (based on mach_absolute_time() - this is a nanosecond counter based on the TSC).
  
• The last position of the erase head.

The user-clients are expected to time themselves based on these three parameters in such a way that they always stay ahead of the playback device and fill the buffer in advance to maintain continuous audio.

The ES137x chipset supports both needed features - generating interrupts and reporting a DMA pointer.
And now for the reason this doesn't work.... [are you ready?]

VMware doesn't emulate the ES137x's DMA pointer

I suspect the reason they don't is because they can't.  They probably pass the buffer on to the host's audio driver and tell it how many samples to play.  They can't tell where the DMA pointer is exacly, but they can generate interrupts in the guest whenever the sample counter completes.  So what they do instead is

• When the channel is off, the DMA pointer is always reported as zero.
  
• When the channel is on, they report the last known value for the pointer when an interrupt fires.  This value stays the same until the next interrupt or until the channel is turned off.

Fortunately, it's possible to compensate for this somewhat by increasing the number of interrupts per buffer.  I've set the number of interrupts to two, so the system functions a little bit like a double-buffering system.  The driver reports every half-buffer that the previous half-buffer is done via the DMA pointer, but only sends an interrupt notification up the stack when the whole buffer wraps around as the user-clients expect.
The first version (1.0.0) used a 64K buffer, the DMA pointer always stayed at zero.  This means the erase head never got run, and the user-clients had no advance notification that any part of the buffer has already been played and can be refilled.
It's possible to increase the number of interrupts per buffer from the host with "pciSound.DAC2InterruptPerSec".  For version 1.0.0, this caused the driver to report every interrupt up the stack, which isn't what the user-clients expect.  The current version 1.0.1 always reports one interrupt per buffer up the stack, but multiple interrupt per buffer will cause the DMA pointer to have a correct value at a higher frequency per buffer.  In theory, higher values of the number of interrupts per buffer should make the driver resemble an accurate DMA pointer more closely, but for some reason I can't figure out this doesn't work.  If I increase the number of interrupt per buffer from 2 to 4, 8 or 16 things start getting worse.
There are still some other things that can be tried

• Even at multiple interrupts per buffer, IOAudioEngine always runs its erase head 4 times per buffer.  This means there can be a delay of up to a quarter-buffer between the time the interrupt is fired and the time IOAudioEngine performs the erasure.  This means that the time window the user-clients have for detecting the erasure after an interrupt can be reduced down from half a buffer to as little as about a quarter of a buffer.  One thing that can be done is to try to browbeat IOAudioEngine into running its erase-head "immediately" after an interrupt instead of on a timer.  Due to the way AppleAC97Audio is designed, this requires some non-trivial redesigning of the code, or some ugly hacks.  Accomplishing this can make sure that user-clients have about a half-buffer of advance notice to fill the buffer.
  
• IOAudioEngine and IOAudioEngineUserClient have functions for helping the user-clients do their timing performClientOutput and calculateSampleTimeout.  I haven't taken a good look at those.  There might be a way to help prod the user-client into refilling the buffer sooner.

This analysis is based on the assumption that the guest OS can monopolize a processor core and run in real-time without yielding.  Things get worse if it has to yield.
Ultimately the stuttering is caused by user-clients falling behind when filling the buffer.  The duration of an audio sample is about 20 microseconds.  Since the CPU/RAM system is about 4 orders of magnitude faster than that, once the user-client gets some CPU time, it quickly makes up the lag.  That's why these imperfections sound the way they do - short and random.  The goal is to get the user-client not to fall behind at all.
There's another issue - I'm testing the driver on a dual-core with hardware virtualization, and I'm not really hearing any stuttering at all anymore.  I suspect people still hearing it are using software virtualization - although I can't be sure.  The problem is that in order to test if modifications I make are helping, I need a machine that can reliably reproduce the problem, and I don't have one.

[TheGreatDeceiver]

Zenith432, on Sep 5 2009, 03:06 PM, said:

There's another issue - I'm testing the driver on a dual-core with hardware virtualization, and I'm not really hearing any stuttering at all anymore.  I suspect people still hearing it are using software virtualization - although I can't be sure.  The problem is that in order to test if modifications I make are helping, I need a machine that can reliably reproduce the problem, and I don't have one.

Zenith, thanks for your detailed answer. I tried to find a setting for hardware virtualization in vmware. How do I know it's using this? I know my i7 920 is set for hardware virtualization, but does vmware use it?

[Zenith432]

TheGreatDeceiver, on Sep 5 2009, 07:45 PM, said:

I tried to find a setting for hardware virtualization in vmware. How do I know it's using this? I know my i7 920 is set for hardware virtualization, but does vmware use it?

You need to make sure it's on in the BIOS -- boot and run BIOS setup.  Look in the menus for "VT" or virtualization and make sure it's enabled (it might already be).  You need to cycle the power after changing this setting.
The setting in VMware for the VM is in Devices->Processors->Execution Mode, "Preferred Mode" should be set to "Automatic".

[smarty94]

Zenith432, on Sep 5 2009, 02:32 PM, said:

You need to make sure it's on in the BIOS -- boot and run BIOS setup.  Look in the menus for "VT" or virtualization and make sure it's enabled (it might already be).  You need to cycle the power after changing this setting.
The setting in VMware for the VM is in Devices->Processors->Execution Mode, "Preferred Mode" should be set to "Automatic".

I'm pretty sure that this is a requirement for Donk's guest package, I can't speak for any other way of running Osx in Vmware

[TheGreatDeceiver]

Zenith432, on Sep 5 2009, 07:32 PM, said:

You need to make sure it's on in the BIOS -- boot and run BIOS setup.  Look in the menus for "VT" or virtualization and make sure it's enabled (it might already be).  You need to cycle the power after changing this setting.
The setting in VMware for the VM is in Devices->Processors->Execution Mode, "Preferred Mode" should be set to "Automatic".

ok, just wanted to make sure I'm not missing anything. Everything you listed is good on my system. Thanks for helping.

btw. I have a really hard time to notice problems. On my system they sound like small scratches on a vinyl.

[Zenith432]

I have an idea.  I'll make an experimental version with a dirty hack to force IOAudioEngine to run its erase head straight after every interrupt so as to maximize the time window for the user-client to refill the buffer.  I'll test it so see that it doesn't crash or reduce playback quality compared to v1.0.1.  If it's ok, I'll post it and people still getting choppy playback can try it and see if it helps.

[Zenith432]

Here we go...

I've bumped the version number to 1.0.2.

If version 1.0.1 is working for you, no need to install this one.  It's experimental.

• IOAudioEngine's erase head now gets run within about 0.1 millisecond of each interrupt.  The interval between interrupts is around 340 milliseconds, so the user-client has almost the entire window to continue refilling the buffer.
  
• I've added a kernel boot parameter "es_oso".  oso stands for "output sample offset".  It's the number of samples that the user-client tries to stay ahead of the playback channel.  The default is 64.  If you're still having problems, try increasing this parameter by factors of two --- 128, 256, ...., 131072, and see if that does anything.

Increasing the number of interrupts per buffer still screws it up and I still don't get why.

Ciao.

Edit (11/8/2009): Attachments removed.  See the link in Post #1 in this thread for the latest version.

[Scorched]

Zenith432, on Sep 6 2009, 01:32 PM, said:

Here we go...

I've bumped the version number to 1.0.2.

If version 1.0.1 is working for you, no need to install this one.  It's experimental.

• IOAudioEngine's erase head now gets run within about 0.1 millisecond of each interrupt.  The interval between interrupts is around 340 milliseconds, so the user-client has almost the entire window to continue refilling the buffer.
  
• I've added a kernel boot parameter "es_oso".  oso stands for "output sample offset".  It's the number of samples that the user-client tries to stay ahead of the playback channel.  The default is 64.  If you're still having problems, try increasing this parameter by factors of two --- 128, 256, ...., 131072, and see if that does anything.

Increasing the number of interrupts per buffer still screws it up and I still don't get why.

Ciao.

How do you change the "es_oso" kernel boot parameter?

[onlytanmoy]

@Zenith >> thanks for this excellent release bro.
I am using VMWare Workstation 6.5.3 in my Windows 7. I have set up Mac OS X Leopard as a virtual machine..initially no device was listed under sound output (naturally no audio)...then i found this thread and installed EnsoniqAudioPCI.mpkg.tar.gz in Mac & voila...sound got enabled

as u can see in the image below..its now displaying a device for sound output..



only prob is audio quality is not at all good..when i play songs via itunes..sound gets distorted...lot of disturbance
any solution for this plz?

Thanks in advance mate.

[TheGreatDeceiver]

Zenith432, on Sep 6 2009, 07:32 PM, said:

Here we go...

I've bumped the version number to 1.0.2.

If version 1.0.1 is working for you, no need to install this one.  It's experimental.

• IOAudioEngine's erase head now gets run within about 0.1 millisecond of each interrupt.  The interval between interrupts is around 340 milliseconds, so the user-client has almost the entire window to continue refilling the buffer.
  
• I've added a kernel boot parameter "es_oso".  oso stands for "output sample offset".  It's the number of samples that the user-client tries to stay ahead of the playback channel.  The default is 64.  If you're still having problems, try increasing this parameter by factors of two --- 128, 256, ...., 131072, and see if that does anything.

Increasing the number of interrupts per buffer still screws it up and I still don't get why.

Ciao.

just installed these on my i7 920 vmware 10.5.8 OSX system. I can hear some improvements, still an occasional hickup but not as bad as it was before. Hard to tell since it was already pretty good before. I think you are definitely going into the right direction... I have not fiddled with kernel boot parameters yet. I guess I use it like this at the darwin prompt?
es_oso=128 or add it into the com.apple.boot.plist under kernel flags?
thank you

[Zenith432]

TheGreatDeceiver, on Sep 12 2009, 06:40 PM, said:

I have not fiddled with kernel boot parameters yet. I guess I use it like this at the darwin prompt?
es_oso=128 or add it into the com.apple.boot.plist under kernel flags?

Yes, exactly.  At the bootloader, click on the keyboard during the time window and type a kernel boot param "es_oso=number".  You can also add to com.apple.boot.plist under the boot options key, either with an editor or with a tool like "OSX86 Tools".

PS
There's one more dose of witch-medicine I can try on the driver which is to double the buffer size from 128KB to the maximum of 256KB.  This seems like a cop-out but why not.  Maybe it's the faster CPUs that are having the problems.  It's possible that the glitches are not caused by user-apps falling behind when filling the buffer but instead by running ahead and mixing future samples into past samples in the mix buffer.

[TheGreatDeceiver]

Zenith432, on Sep 13 2009, 09:42 PM, said:

Yes, exactly.  At the bootloader, click on the keyboard during the time window and type a kernel boot param "es_oso=number".  You can also add to com.apple.boot.plist under the boot options key, either with an editor or with a tool like "OSX86 Tools".

PS
There's one more dose of witch-medicine I can try on the driver which is to double the buffer size from 128KB to the maximum of 256KB.  This seems like a cop-out but why not.  Maybe it's the faster CPUs that are having the problems.  It's possible that the glitches are not caused by user-apps falling behind when filling the buffer but instead by running ahead and mixing future samples into past samples in the mix buffer.

interesting experiment. run a sound file with on click in it that spans 2minutes with the click for a msec. run the file in a sound editor and listen when the click occurs and see whether it falls right onto the peak in the sound editor

edit: finally put my headphones on to listen carefully. the scratch sound (it does exactly sound like a scratch on an old vinyl) is very regular. when there is silence there is not scratch sound, once sound comes on, it comes every 1-2 seconds or so. It also has an amplitude relative to the music that plays at the moment. nothing else on mine, just that scratch sound. when played on host system, the songs play fine (sanity check - somebody scratched my mp3   ).

[Ranguvar]

Zenith432, on Sep 13 2009, 03:42 PM, said:

Yes, exactly.  At the bootloader, click on the keyboard during the time window and type a kernel boot param "es_oso=number".  You can also add to com.apple.boot.plist under the boot options key, either with an editor or with a tool like "OSX86 Tools".

PS
There's one more dose of witch-medicine I can try on the driver which is to double the buffer size from 128KB to the maximum of 256KB.  This seems like a cop-out but why not.  Maybe it's the faster CPUs that are having the problems.  It's possible that the glitches are not caused by user-apps falling behind when filling the buffer but instead by running ahead and mixing future samples into past samples in the mix buffer.

Please do try this
I'm running a 2.4GHz Core 2 Quad Q6600 (the VM detects a 4.3GHz Core 2 Solo), and I can't get the stuttering to go away.  Tried the MIDI app, tried lots of different values for es_oso, etc. -- nothing seems even to change the amount of stuttering.

In fact, I'll try underclocking my CPU...

Thanks very, very much for all you've done!  

[talipo]

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

[markeddy998]

Zenith, are your audio drivers 32bit or are they compatible with both 32-bit and 64-bit flavors of 10.6 Snow Leopard?

Thanks.

[an1r0n]

Zenith432, on Sep 13 2009, 09:42 PM, said:

Yes, exactly.  At the bootloader, click on the keyboard during the time window and type a kernel boot param "es_oso=number".  You can also add to com.apple.boot.plist under the boot options key, either with an editor or with a tool like "OSX86 Tools".

PS
There's one more dose of witch-medicine I can try on the driver which is to double the buffer size from 128KB to the maximum of 256KB.  This seems like a cop-out but why not.  Maybe it's the faster CPUs that are having the problems.  It's possible that the glitches are not caused by user-apps falling behind when filling the buffer but instead by running ahead and mixing future samples into past samples in the mix buffer.

Zenith,

Great job, just one thing thats on my mind. Before I continue I already configured OS X on VMware Workstation following Donk's guide and installing your drivers.

I realized that the choppy sound problem could be because OS X doesn't recognize correcty processor and FSB. Possible solution is to install latest Chameleon bootloader since they solved A LOT problems (including CPU and FSB recognition).

I would try it by myself but I have deleted my OS X virtual machine since I'm desperate for hard disk space : )

Please try it!

Cheers and keep up with excellent work!

[JasonTan]

Thanks for the audio driver - you've made my day!!

[Beerkex'd]

Thanks for the AC97 driver rebuild. I'm using it on the P4 hackintosh in my sig and it works great.

The old driver I was using was filling up the logs with debug info and slowing down my boot time. This one doesn't.

[que2]

Beerkex'd, on Feb 16 2010, 04:14 AM, said:

Thanks for the AC97 driver rebuild. I'm using it on the P4 hackintosh in my sig and it works great.

The old driver I was using was filling up the logs with debug info and slowing down my boot time. This one doesn't.

I am trying to get this driver to work with Tiger 10.4.8 in VMWARE 7. Is this driver leopord dependant or will it work in Tiger? I have tried the old maxxus and this driver. I just do not have a clue of how I can get sound to work. I do not want to switch to leopard, I want to find a way to get sound to work in Tiger. Any clue of how I can get this to work or your driver to work with Tiger.

Any help would be greatly appreciated.

Thanks already!

[Donk]

que2, on Feb 23 2010, 01:41 PM, said:

I am trying to get this driver to work with Tiger 10.4.8 in VMWARE 7. Is this driver leopord dependant or will it work in Tiger? I have tried the old maxxus and this driver. I just do not have a clue of how I can get sound to work. I do not want to switch to leopard, I want to find a way to get sound to work in Tiger. Any clue of how I can get this to work or your driver to work with Tiger.

Any help would be greatly appreciated.

Thanks already!

It was written for Leopard. You could try getting the code and re-compiling for Tiger, but not sure how much you would need to change if anything.