Questions regarding workaround for VMware

Questions regarding workaround for VMware

[Bankim Bhavsar]

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.

Re: Questions regarding workaround for VMware

[Takashi Iwai]

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

Re: Questions regarding workaround for VMware

[Bankim Bhavsar]

[-- 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

Re: Questions regarding workaround for VMware

[Takashi Iwai]

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

Re: Questions regarding workaround for VMware

[Bankim Bhavsar]

>> > 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.

Re: Questions regarding workaround for VMware

[Colin Guthrie]

'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/]

Re: Questions regarding workaround for VMware

[Raymond Yau]

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
>