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

[Mark Greenwood]

On Sunday 22 February 2009 19:37:11 Lennart Poettering 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.
> 

<snip>

Very, very, interesting.

As someone who has done a fair amount of audio work on Linux I normally build my own kernel as a matter of course, since none of them (even the ones that claim to be 'real time') are really up to the sort of low latency stuff I'm trying to do. (That said, I've never tried Fedora :) ). I've found it quite possible to achieve latencies of < 1ms on decent hardware, so yes, 210ms is pathetic :) On the other hand, that system uses nvidia drivers so I think they're less of an issue.

Lennart, are there any definite things that you feel should be built into a kernel, or any things that definitely should not be in a kernel, for g-f to work properly? I have a short list of things I've decided must not be defined in my RT kernels for audio work. I'd be very interested in doing some experiments with the Mandriva and Ubuntu setups I'm using because g-f doesn't seem to be working very well on either of them.

Thanks,

Mark

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