[pulseaudio-discuss] crackle and stutter

Tue Apr 12 09:00:35 PDT 2011

Hi,

On Tue, Apr 12, 2011 at 11:14 AM, Brian J. Murrell
<brian at interlinx.bc.ca> wrote:
> It seems inevitable that my pulse audio server
> (0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 on Ubuntu Maverick)
> will start sounding crackly and stuttery when an application wants to
> send "notification" type sounds.

Can you give an example of what application(s) in particular trigger
this? Is it reproducible 100% of the time, or just sometimes? How is
your CPU load when this is occurring?

>
> When this happens, about the only useful thing I see in the "-vvv"
> output is:
>
> D: alsa-sink.c: Requested to rewind 22988 bytes.
> D: alsa-sink.c: Limited to 22988 bytes.
> D: alsa-sink.c: before: 5747
> D: alsa-sink.c: after: 5747
> D: alsa-sink.c: Rewound 22988 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 22988 bytes on render memblockq.
> D: sink-input.c: Have to rewind 22988 bytes on render memblockq.
> D: sink-input.c: Have to rewind 11496 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 23120 bytes.
> D: alsa-sink.c: Limited to 23120 bytes.
> D: alsa-sink.c: before: 5780
> D: alsa-sink.c: after: 5780
> D: alsa-sink.c: Rewound 23120 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 23120 bytes on render memblockq.
> D: sink-input.c: Have to rewind 23120 bytes on render memblockq.
> D: sink-input.c: Have to rewind 11560 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 21480 bytes.
> D: alsa-sink.c: Limited to 21480 bytes.
> D: alsa-sink.c: before: 5370
> D: alsa-sink.c: after: 5370
> D: alsa-sink.c: Rewound 21480 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 21480 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21480 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10740 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 21848 bytes.
> D: alsa-sink.c: Limited to 21848 bytes.
> D: alsa-sink.c: before: 5462
> D: alsa-sink.c: after: 5462
> D: alsa-sink.c: Rewound 21848 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 21848 bytes on render memblockq.
> D: sink-input.c: Have to rewind 21848 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10924 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 20212 bytes.
> D: alsa-sink.c: Limited to 20212 bytes.
> D: alsa-sink.c: before: 5053
> D: alsa-sink.c: after: 5053
> D: alsa-sink.c: Rewound 20212 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 20212 bytes on render memblockq.
> D: sink-input.c: Have to rewind 20212 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10108 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 20336 bytes.
> D: alsa-sink.c: Limited to 20336 bytes.
> D: alsa-sink.c: before: 5084
> D: alsa-sink.c: after: 5084
> D: alsa-sink.c: Rewound 20336 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 20336 bytes on render memblockq.
> D: sink-input.c: Have to rewind 20336 bytes on render memblockq.
> D: sink-input.c: Have to rewind 10168 bytes on implementor.
> D: source.c: Processing rewind...
> D: protocol-native.c: Underrun on 'Playback Stream', 0 bytes in queue.
> D: protocol-native.c: Requesting rewind due to rewrite.
> D: alsa-sink.c: Requested to rewind 19012 bytes.
> D: alsa-sink.c: Limited to 19012 bytes.
> D: alsa-sink.c: before: 4753
> D: alsa-sink.c: after: 4753
> D: alsa-sink.c: Rewound 19012 bytes.
> D: sink.c: Processing rewind...
> D: sink-input.c: Have to rewind 19012 bytes on render memblockq.
> D: sink-input.c: Have to rewind 19012 bytes on render memblockq.
> D: sink-input.c: Have to rewind 9508 bytes on implementor.
>
> I'm not really sure what this is telling me though.  Is the above
> normal?  Is there something else I should be looking for?

Some amount of rewinds are normal. Especially when the server first
starts up, or when the amount of latency demanded by an application is
very low while system load is high. But excessive rewinds can be due
to a driver bug in ALSA (this would have to be specific to your
hardware since I can't reproduce the issue here on Maverick). I like
to compare it to an anti-lock break system: if it engages at the right
time, it's useful, but if it engages erroneously it can be dangerous.

If you're getting lots of rewinds while the server is underway with a
relatively low CPU load, you might want to check out what David H.
from Canonical has been doing to try and fight rewinds in gstreamer
(not sure if that is related to your issue or not):
http://gstreamer-devel.966125.n4.nabble.com/Fighting-rewinds-pulseaudio-crash-update-td3248107.html

I think David is on this list, too, so maybe he will chime in :) Have
your patches been included as a Maverick SRU, David?

Also (back to addressing Brian), it's always useful to post the output
of running alsa-info.sh with problems like this:
http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-info.sh

I can't speak to the Ubuntu SRU process, but it's quite possible that
a stable update fixing this issue for Maverick will never arrive
(especially if nobody gets to the bottom of the issue). Your
alternatives are to try Natty (it's stabilizing well in Beta 2-ish
now), another more recent distro, or stay where you are but compile
PulseAudio from git (stable-queue branch is a good choice). The
problem might already be fixed upstream.

As a last-ditch workaround you might try disabling time-based
scheduling, but troubleshooting further first would be preferred :)
With a bit more work, a fix could be forthcoming, and then we could
resolve the issue for everyone who has your particular (or shall I
say, peculiar?) sound chipset.

Sean

>
> During these periods of crackle and stutter, other "continuous" sound
> output type applications, like audio/video apps seem to stutter as well
> as if they are being blocked on their output by the pulse server and
> it's attempting to handle these other "periodic" type applications that
> send notification sounds and so on.
>
> Thots?
>
> b.
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
>