[pulseaudio-discuss] Distribution kernels and glitch-free (Packagers, read this!)

Tue May 12 14:11:59 PDT 2009

On Sun, Feb 22, 2009 at 3:37 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> Heya!
>
> As one result of the alsa-time-test testing (see that last mail of
> mine regarding broken sound drivers) input I got from folks, I learned
> how very different the different distribution kernels actually
> behave. They are much more different than i actually assumed.
>
> Apparently OpenSUSE ships a kernel (2.6.27.7-9-pae) that causes
> scheduling latencies of > 210ms. That is a lot. That is really really
> really a lot. Other non-Fedora distributions apparently do something similar.
>
> The parameters in the glitch-free logic are tuned for Fedora-kernels
> that easily give latencies of 5ms or so.
>
> ALSA artificially limits the overall buffer size to 64k (i.e. 371ms on
> 44100hz/2ch/s16le). That this size is not that much when speaking of
> scheduling latencies of 210ms should be obvious.

I just tried playing a small file and ALSA gave me a 88,200 byte buffer.

mpc5200-psc-ac97 f0002200.sound:
psc_ac97_hw_analog_params(substream=c7929700) p_size=5513
p_bytes=22052 periods=4 buffer_size=22052  buffer_bytes=88208
channels=2 rate=44100 format=3

> Now, the glitch-free mode in PA is a major departure from the
> traditional playback mode. In traditional playback mode the sound card
> buffer is filled as soon as at least one 'fragment' of it ran
> empty. Usually 4 fragments or so are used, i.e. the fill level will
> oscillate between 'full' and 'full minus one fragment size minus the
> scheduling latency'. If we have a buffer of 371ms we have a fragment
> size of 91ms. With a kernel like that OpenSUSE kernel hence the fill
> level oscillates between 371ms and 70ms. Which of course is usually
> good enough to not get a drop out. Should a drop out happen nonethless
> we continue as if nothing happened given that fragment settings cannot
> be reconfigured during runtime.
>
> Now, let's have a look what this means for glitch-free mode. In g-f
> mode we disable sound card interrupts (and get rid of 'fragments'

Doing that is wrong. You do not want to disable these interrupts
totally. It is fine to disable the interrupt at end of period. But you
need to keep the end of the valid buffer programmed into the DMA
hardware. If DMA overruns the end of valid data it needs to generate
an interrupt.  That interrupt indicates an error condition. If
everything is working properly you'll never hit that interrupt.

DMA hardware doesn't care about fragments, fragments are an ALSA
construct. DMA hardware just cares about the beginning and ending
physical address. If it supports scatter/gather you can chain multiple
sets of physical addresses together.

> entirely) as far as possible to minimize power consumption. We
> schedule audio via system timers instead of the sound card's fragment
> logic. Instead of already filling up after a single fragment was
> played we delay the fill up until only 10 ms are still left in the
> buffer (in PA 0.9.14 that is, i increased the default to 20ms now on
> .15). i.e. with a Fedora scheduling latency of 5ms the buffer fill
> level will hence oscillate between 371ms and 5ms. Still good enough to
> not get into drop outs. If a drop out happens nonethelless we will
> double the 10 ms to 20ms and go on. If that still turns out to not be
> enough we double again, and so on. If this logic with these parameters
> is run on an OpenSuse kernel, drop-outs will necessarily happen right
> away. Because 10ms minus the sched latency of 210ms equals
> FAILURE. And doubling the wakeup time again and again will require

You are taking a hard path to solving this problem. If a kernel has
500ms latency just calculate how big of buffer you need and make sure
ALSA gives it to you. Modern DMA hardware does not have 64Kb limits.
64Kb limits are from the era of the 8086 chip. Fix ALSA to use bigger
DMA buffers.

44.1Khz * 16b * 2 = 176,400 bytes per second. A 64KB buffer can handle
371ms best case, but other things have latencies so 200ms is more
realistic. You have no choice, the buffer has to be big enough to
handle the kernel latencies. If it is not your audio will drop out.
Playing with keeping the buffer closer to the full mark is curing the
symptom, not fixing the cause.

To get a lower audio latency the kernel has to be fixed.

> quite a number of iterations, i.e. more than just a few underruns at
> the beginning. Also the doubling will quickly come near to the full
> buffer size of 371ms causing a lot of CPU to be eaten, since we will
> wake up very very often.
>
> So, what do we read from this?
>
> 0) Fedora is awesome, other distributions suck ;-)
>
> 1) For fucks sakes: get your bloody kernels fixed. Enable preempt, set
>   HZ to 1000. Get rid of low-quality drivers that block the
>   CPU. Latencies of 210ms is *REALLY NOT NECESSARY*.

Why do you want HZ at 1000? Filling the buffers on timer ticks should
work fine at 100Hz. This is taking more power than leaving ALSA alone
and letting it fill the buffer on the audio period interrupt.  ALSA
only asks for 8Hz period interrupts.

The problem you are getting into with the 8Hz period ticks is
aggravated by the kernel latency.

8Hz = 125ms + 210ms latency = 330ms.  You just need a bigger buffer in
this case. Probably about 120KB.

If ALSA had a better DMA design if could handle variable sized
buffers. Measure the system latency and dynamically increase the size
of the ALSA buffer pool if a DMA overrun ever occurs.  DMA hardware
supports this, it's ALSA that doesn't.

> 2) If you want to stick with your crap kernel, then either disable g-f
>   entirely or adjust the #defines at the top of
>   src/modules/alsa-sink.c and src/modules/alsa-source.c.
>
> Thank you very much,
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>

-- 
Jon Smirl
jonsmirl at gmail.com