* Questions regarding workaround for VMware @ 2009-08-28 18:29 Bankim Bhavsar 2009-08-28 19:51 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Bankim Bhavsar @ 2009-08-28 18:29 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, akataria, bbhavsar 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=79452f0a28aa5a40522c487b42a5fc423647ad98 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions regarding workaround for VMware 2009-08-28 18:29 Questions regarding workaround for VMware Bankim Bhavsar @ 2009-08-28 19:51 ` Takashi Iwai 2009-09-13 18:17 ` Bankim Bhavsar 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2009-08-28 19:51 UTC (permalink / raw) To: Bankim Bhavsar; +Cc: alsa-devel, akataria, bbhavsar 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=79452f0a28aa5a40522c487b42a5fc423647ad98 > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions regarding workaround for VMware 2009-08-28 19:51 ` Takashi Iwai @ 2009-09-13 18:17 ` Bankim Bhavsar 2009-09-15 11:00 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Bankim Bhavsar @ 2009-09-13 18:17 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, akataria, bbhavsar [-- Attachment #1: Type: text/plain, Size: 2324 bytes --] 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. [-- Attachment #2: ALSAUnderrun.log --] [-- Type: text/x-log, Size: 4597 bytes --] Playing WAVE 'sample.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo ALSA <-> PulseAudio PCM I/O Plugin Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 underrun!!! (at least 10.708 ms long) Status: state : XRUN trigger_time: 1252864094.528012000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 34.164 ms long) Status: state : XRUN trigger_time: 1252864094.551488000 tstamp : 0.000000 delay : 0 avail : 369 avail_max : 24369 underrun!!! (at least 31.420 ms long) Status: state : XRUN trigger_time: 1252864094.598043000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 20.394 ms long) Status: state : XRUN trigger_time: 1252864094.648311000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 26.042 ms long) Status: state : XRUN trigger_time: 1252864094.690683000 tstamp : 0.000000 delay : 0 avail : 369 avail_max : 24000 underrun!!! (at least 18.061 ms long) Status: state : XRUN trigger_time: 1252864094.730349000 tstamp : 0.000000 delay : 0 avail : 12369 avail_max : 24369 underrun!!! (at least 368.755 ms long) Status: state : XRUN trigger_time: 1252864094.761685000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 26488 underrun!!! (at least 6.058 ms long) Status: state : XRUN trigger_time: 1252864095.150158000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 360.790 ms long) Status: state : XRUN trigger_time: 1252864095.168713000 tstamp : 0.000000 delay : 0 avail : 17852 avail_max : 29072 underrun!!! (at least 18.394 ms long) Status: state : XRUN trigger_time: 1252864095.550346000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 940.152 ms long) Status: state : XRUN trigger_time: 1252864095.582024000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 31150 underrun!!! (at least 19.771 ms long) Status: state : XRUN trigger_time: 1252864096.537351000 tstamp : 0.000000 delay : 0 avail : 18760 avail_max : 30760 underrun!!! (at least 28.983 ms long) Status: state : XRUN trigger_time: 1252864096.570068000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 13.588 ms long) Status: state : XRUN trigger_time: 1252864096.612568000 tstamp : 0.000000 delay : 0 avail : 17499 avail_max : 24000 underrun!!! (at least 19.823 ms long) Status: state : XRUN trigger_time: 1252864096.639219000 tstamp : 0.000000 delay : 0 avail : 5499 avail_max : 24000 underrun!!! (at least 848.805 ms long) Status: state : XRUN trigger_time: 1252864096.672237000 tstamp : 0.000000 delay : 0 avail : 3014 avail_max : 34945 underrun!!! (at least 3.010 ms long) Status: state : XRUN trigger_time: 1252864097.541168000 tstamp : 0.000000 delay : 0 avail : 369 avail_max : 24000 underrun!!! (at least 18.652 ms long) Status: state : XRUN trigger_time: 1252864097.557743000 tstamp : 0.000000 delay : 0 avail : 18369 avail_max : 24369 underrun!!! (at least 548.891 ms long) Status: state : XRUN trigger_time: 1252864097.589739000 tstamp : 0.000000 delay : 0 avail : 18096 avail_max : 32584 underrun!!! (at least 45.578 ms long) Status: state : XRUN trigger_time: 1252864098.159709000 tstamp : 0.000000 delay : 0 avail : 19707 avail_max : 37707 underrun!!! (at least 37.704 ms long) Status: state : XRUN trigger_time: 1252864098.220655000 tstamp : 0.000000 delay : 0 avail : 369 avail_max : 24369 [-- Attachment #3: Type: text/plain, Size: 160 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions regarding workaround for VMware 2009-09-13 18:17 ` Bankim Bhavsar @ 2009-09-15 11:00 ` Takashi Iwai 2009-09-17 0:27 ` Bankim Bhavsar 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2009-09-15 11:00 UTC (permalink / raw) To: Bankim Bhavsar; +Cc: alsa-devel, akataria, bbhavsar 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions regarding workaround for VMware 2009-09-15 11:00 ` Takashi Iwai @ 2009-09-17 0:27 ` Bankim Bhavsar 2009-09-17 13:06 ` Colin Guthrie 0 siblings, 1 reply; 7+ messages in thread From: Bankim Bhavsar @ 2009-09-17 0:27 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, akataria, bbhavsar >> > 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=ed3da3d9a0ef13c6fe1414ec73c9c1be12747b62 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions regarding workaround for VMware 2009-09-17 0:27 ` Bankim Bhavsar @ 2009-09-17 13:06 ` Colin Guthrie 2009-09-18 7:00 ` Raymond Yau 0 siblings, 1 reply; 7+ messages in thread From: Colin Guthrie @ 2009-09-17 13:06 UTC (permalink / raw) To: alsa-devel '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 -- 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/] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions regarding workaround for VMware 2009-09-17 13:06 ` Colin Guthrie @ 2009-09-18 7:00 ` Raymond Yau 0 siblings, 0 replies; 7+ messages in thread From: Raymond Yau @ 2009-09-18 7:00 UTC (permalink / raw) To: alsa-devel 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-09-18 7:00 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-28 18:29 Questions regarding workaround for VMware Bankim Bhavsar 2009-08-28 19:51 ` Takashi Iwai 2009-09-13 18:17 ` Bankim Bhavsar 2009-09-15 11:00 ` Takashi Iwai 2009-09-17 0:27 ` Bankim Bhavsar 2009-09-17 13:06 ` Colin Guthrie 2009-09-18 7:00 ` Raymond Yau
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.