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
