At Fri, 28 Aug 2009 11:29:52 -0700, Bankim Bhavsar wrote:
Takashi I came across a workaround for VMware in ALSA kernel code http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
Thanks for the fix.
In the comments you mention about inaccurate timer source. Could you elaborate on the problem?
The problem is that the irq timing emulated on vmware isn't always accurate. The sound hardware is supposed to issue an irq at the programmed buffer period. On VMware, this irq generation seems to be done based on the system timer (or alike), thus it's not generated at the accurate timing that the hardware should give.
The driver has no idea whether it's on VM, thus assumed that the IRQ must come accurately more or less. In the recent code, there are some additions to correct the DMA position more to believe the accuracy of the IRQ than the position calculated from the hardware register. This caused a regression on VMware. My patch fixed that, at least, for VMware in the stance of previous versions.
As of now we see that sound apps running in Fedora 11 guest OS with kernel 2.6.29.4-167 don't make any progress and can hang window manager like Metacity.
VMware virtualizes Ensoniq ES1371 sound device.
Is there something specific you would like us to fix in our virtual sound device or timer source?
Well, the only question is how can we get the programmed sound IRQ more accurately... If hrtimer with the fine timer source is available, this could be emulated well, I guess.
thanks,
Takashi