At Sun, 13 Sep 2009 11:17:08 -0700, Bankim Bhavsar wrote:
On Fri, Aug 28, 2009 at 12:51 PM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 28 Aug 2009 11:29:52 -0700, Bankim Bhavsar wrote:
Takashi I came across a workaround for VMware in ALSA kernel code 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.
Thanks for the explanation, Takashi. Sorry for the delayed response.
I tested with the fix for VMware with 2.6.31rc9 kernel. Sound playback suffers from underruns and app terminates prematurely. I've attached the output of "aplay sample.wav -vvv".
I compiled kernel with following config options turned on CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_VERBOSE=y CONFIG_SND_PCM_XRUN_DEBUG=y
and set /proc/asound/card0/pcm0p/xrun_debug to 1.
I can't seem to find ALSA xrun_debug log messages with dmesg. Am I looking in the wrong place?
As far as the timing of sound IRQ goes, with our emulation of ENS1371 delay in firing interrupt ranges from 50-500 usecs. Is that large enough to cause xruns with recent changes?
It should be fine. AFAIK, the problem was reported only by one guy, and maybe it's a kernel config issue, e.g. low HZ and/or no preempt. I can't find where the data pointer is now. Will report you back if I find from my archive.
Linux guests with kernel version 2.6.31+ running under VMware are affected currently.
Let me know if you need more information.
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.
I'll consult our timer experts in VMware and get back to you on this question.
That'll be great.
thanks,
Takashi