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

[Lennart Poettering]

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.

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

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