[pulseaudio-discuss] Very crackly audio and crashing from cpu overload

[Lennart Poettering]

On Thu, 08.01.09 23:03, Chris (chris1.noreply at googlemail.com) wrote:

> 
> 2009/1/8 Chris <chris1.noreply at googlemail.com>:
> > 2009/1/8 Lennart Poettering <lennart at poettering.net>:
> > I've been playing with the default-fragments and
> > default-fragment-size-msec settings but they don't seem to be having
> > any effect. I'm just getting occasional skipping now - maybe one skip
> > of a fraction of a second every 3 to 5 seconds. The bad crackling went
> > when I set tsched=1.
> 
> Think I've figured out something interesting... when I first start
> playing music, it works reasonably well, but after a while, maybe 30
> seconds, there is a glitch. At soon as there is a glitch, a message
> appears in /var/log/messages about increasing the wakeup watermark.
> Then the next glitch occurs after about 15 seconds and the watermark
> is increased. Basically, the glitches become more and more frequent as
> the watermark is increased. Here's the log output...
> 
> Jan  8 22:58:20 localhost pulseaudio[2772]: module-alsa-sink.c:
> Increasing wakeup watermark to 5.99 ms
> Jan  8 22:58:45 localhost pulseaudio[2772]: module-alsa-sink.c:
> Increasing wakeup watermark to 11.97 ms
> Jan  8 22:59:15 localhost pulseaudio[2772]: module-alsa-sink.c:
> Increasing wakeup watermark to 23.95 ms
> Jan  8 22:59:17 localhost pulseaudio[2772]: module-alsa-sink.c:
> Increasing wakeup watermark to 47.89 ms
> Jan  8 22:59:24 localhost pulseaudio[2772]: module-alsa-sink.c:
> Increasing wakeup watermark to 71.27 ms
> 
> It never goes above that 71.27ms point but the glitches are frequent
> from that point on until I restart pulse.


When PA detects an underrun it thinks: "ah, so we didn't wake up in
time to fill the playback buffer again, so next time lets wake up a
bit earlier to increase the chance that we can fill up the playback
buffer in time". That means the wakeup watermark (i.e. the time PA
estimnates it needs to fill up the buffer again before the buffer
might run empty) is doubled on each drop out. However we don't
increase the wakeup boundary without limits -- instead we make sure we
will still sleep for at least half the buffer size. That's why the
watermark doubles on each drop-out until an upper limit is reached.

Now the question is of course why you get those drop outs in the first
place. There might be three reasons for that:

1) The driver is broken and lies about the timing parameters (i.e. the
   playback position of the hardware). PA relies on correct timing
   information from the driver to estimate when to wake up next. This
   would need to be fixed in the ALSA driver. 

2) The estimnation logic in PA is broken. i.e. although we got correct
   timing information from the driver we miscalculate the wakeup
   time because the retard who wrote that code (read: me) made a
   mistake when he coded it because that stuff is a bit complex and he
   is not. This would need fixing in PA itself.

3) We estimate everything correctly and set up our timers correctly,
   but the kernel doesn't obey and doesn't wake us up in time. Bad bad
   kernel. There might be a lot of reasons for that. Usually this has
   todo with drivers that block the CPU for too long and thus bar
   userspace from getting scheduled in time. Particularly bad at this
   are closed-source drivers (ndis, nvidia). The tool "latencytop" may
   be used to figure out what is going on.

I am tempted to blame #1 an #3 for most incarnations of this bug,
because it is only triggered by very specific hardware setups -- and
of course because software I write doesn't have any bugs!

I hope this helps a bit.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4