[alsa-devel] Questions regarding workaround for VMware
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?
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?
Thanks, Bankim.
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
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?
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.
-- Bankim.
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
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.
For Linux guests virtual sound device generated 50 interrupts per sec. This was leading to hw_ptr_base re-calculation in snd_pcm_update_hw_ptr_interrupt() on every interrupt after this commit http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=ed3da3d9a0ef13...
We are fixing our sound card emulation for Linux guest OSes such that interrupts are generated at programmed buffer period. This helps improve playback quality with 2.6.31rc9+ kernels.
Thanks for the pointers, Takashi!
On a side-note there seems to be some change in PulseAudio bring shipped with Ubuntu 9.10 over 9.04 that affects sound playback quality. With PulseAudio in 9.10, programmed DMA buffer is 64k and num_periods is always 1 and thereby number of interrupts generated per sec is just 2 for 16-bit, 44Khz, stereo. IMO the number interrupts is too low and this leads to under-runs. Whats the reason for choosing always 1 period and having large buffer/period size (power-savings?)?
If I disable PulseAudio in 9.10, programmed DMA buffer is 64k with 16 periods each of size 4k and virtual sound device would generate 46-48 interrupts per sec. With this setting sound playback quality is good.
--Bankim.
'Twas brillig, and Bankim Bhavsar at 17/09/09 01:27 did gyre and gimble:
On a side-note there seems to be some change in PulseAudio bring shipped with Ubuntu 9.10 over 9.04 that affects sound playback quality. With PulseAudio in 9.10, programmed DMA buffer is 64k and num_periods is always 1 and thereby number of interrupts generated per sec is just 2 for 16-bit, 44Khz, stereo. IMO the number interrupts is too low and this leads to under-runs. Whats the reason for choosing always 1 period and having large buffer/period size (power-savings?)?
If I disable PulseAudio in 9.10, programmed DMA buffer is 64k with 16 periods each of size 4k and virtual sound device would generate 46-48 interrupts per sec. With this setting sound playback quality is good.
I'm not sure about Ubuntu setup but the disabling of interupts and using timers is indeed all about power savings. The wakeup time is dynamically adjusted when an underrun occurs so as to avoid it in the future.
Some Nokia/Intel folks (can't remember which) are experimenting with very large latencies (e.g. up to about 10s) in order to get maximum power savings.
You can read more about it here: http://0pointer.de/blog/projects/pulse-glitch-free.html
You can disable this timer based scheduling by passing the argument tsched=0 to module-hal-detect or module-udev-detect (whichever is in use: the latter obsoleting the former) in /etc/pulse/default.pa
Col
2009/9/17 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Bankim Bhavsar at 17/09/09 01:27 did gyre and gimble:
On a side-note there seems to be some change in PulseAudio bring shipped with Ubuntu 9.10 over 9.04 that affects sound playback quality. With PulseAudio in 9.10, programmed DMA buffer is 64k and num_periods is always 1 and thereby number of interrupts generated per sec is just 2 for 16-bit, 44Khz, stereo. IMO the number interrupts is too low and this leads to under-runs. Whats the reason for choosing always 1 period and having large buffer/period size (power-savings?)?
If I disable PulseAudio in 9.10, programmed DMA buffer is 64k with 16 periods each of size 4k and virtual sound device would generate 46-48 interrupts per sec. With this setting sound playback quality is good.
I'm not sure about Ubuntu setup but the disabling of interupts and using timers is indeed all about power savings. The wakeup time is dynamically adjusted when an underrun occurs so as to avoid it in the future.
Is it correct to use the term "the disabling of interrupt" ?
If the hardware interrupt is disabled , you will need the driver to use the timer to update the hardware pointer.
"ping pong" buffering need at least two periods per buffer
aplay does not accept one period per buffer
Why do PA server use one period per buffer ? Is it a driver bug ? ( e.g emu10k1 and intel8x0 have special code to handle one period
An application using mmap read/write should not allow underrun/overrun occur
Some Nokia/Intel folks (can't remember which) are experimenting with very large latencies (e.g. up to about 10s) in order to get maximum power savings.
You can read more about it here: http://0pointer.de/blog/projects/pulse-glitch-free.html
You can disable this timer based scheduling by passing the argument tsched=0 to module-hal-detect or module-udev-detect (whichever is in use: the latter obsoleting the former) in /etc/pulse/default.pa
Col
--
Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/
Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (4)
-
Bankim Bhavsar -
Colin Guthrie -
Raymond Yau -
Takashi Iwai