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

[Chris]

2009/1/8 Lennart Poettering <lennart at poettering.net>:
> 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.

Very useful info, thanks. I'm probably gonna call it a night now but
I'll do my best to investigate each of those options in the next few
days. For me, #3 sounds most probable since I'm running the dreaded
nvidia blob. I wanted compiz eye-candy although I've not managed to
get it working yet and Xorg still seems to be using a lot of CPU so
it's probably the nvidia driver to blame.

I'll be sure to let you know how it pans out because you've been very
helpful. Keep up the good work!

Cheers, Chris.