I've read that CoreAudio doesn't use HPET, but instead relies on the time stamp counters and some funny calculations with CPU bus speed etc. So, FSB speed does matter.
So, looking at dmesg output, nawcoms kernel seems to blindly double the reported FSB speed which seems to completely mess up the TSC.
FSB was reported as 201 MHz (which is correct actually), and corrected it to 437 MHz. WTF...
I now use AnV's 10.6.8 V8_2 kernel, which at first set the corrected FSB speed to 103 MHz and corrected it to 237MHz. Sound was already a lot less crackling, but still: too fast feeding samples. So I added following to my boot options:
fsb=200000000 busratio=16And now:
TSC: Reported FSB: 200.0000MHz, corrected FSB: 200.866380MHz TSC: Verification of clock speed failed. Fallback correction was performed. Please upgrade bootloader. TSC: Frequency = 3213.862080MHz, FSB frequency = 200.866380MHz, bus ratio = 16
That looks better - and Sound is waaaaaaay more usable now. Still not enough to actually listen to music, though.
So I raised the sample buffer size of the ensoniq driver by using the boot parameter
es_oso=256(the default is 64). And now I'm almost getting there. It's still a bit glitchy but almost usable.
I'll try to get the FSB a little bit below 200MHz, because vmware states that the guest should run a tick slower than the host , and try to play with es_oso buffer size
 http://www.vmware.co...ualMachines.pdf - a little outdated, virtual HPET is available in Workstation 9/Fusion 5 meanwhile.
Hope this helps a bit.