pulseaudio deeply unreliable (Fedora 10)

[Richard Shaw]

On Sat, Mar 7, 2009 at 3:03 AM, Raymond C. Rodgers <sinful622 at gmail.com> wrote:
> Raymond C. Rodgers wrote:
>>
>> I'm getting the stuttering, static, and crashes too, and periodically
>> something will happen with pulseaudio that results in thousands (at least)
>> of identical error messages appearing in /var/log/messages. I looked up the
>> error (I can't remember what it is off-hand) and the pulseaudio guys are
>> saying that it's a bug in alsa, and the alsa guys seem to be working on a
>> bug directly related to that error, but the symptoms of the bug they're
>> fixing don't match what I'm seeing with pulse...
>>
>> Frankly, I don't care where the hell the problem is, I just want my audio
>> working clearly and properly. I'll post the error message when I get a
>> chance, but even if alsa is the problem it doesn't explain why I've seen
>> pulseaudio die between the time I start it in a terminal window and the time
>> Banshee finishes loading so I can actually play some audio.
>>
>> Raymond
>
> The error message I mentioned above is:
>
> module-alsa-sink.c: ALSA woke us up to write new data to the device, but
> there was actually nothing to write! Most likely this is an ALSA dr
> iver bug. Please report this issue to the PulseAudio developers.
>
> Raymond

It's very possible that's that problem. I'm not a developer, but I
monitor the pulseaudio mailing list since it's still under heavy
development. No fixes here yet but the following copy of a message
might help explain the problem better:
---
On Fri, 27.02.09 16:09, Zhang, Xing Z (xing.z.zhang at intel.com) wrote:

> Hi Lennart:

Heya!

> 	We met an issue when do a stress test on PA.
> 	We play ~10 streams and do pause/resume on them at will. The PA terminated after 2 ~ 5 minutes.
>
> Below are logs:
>
> E: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the ALSA developers. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail_update() returned 0.
> W: ratelimit.c: 32 events suppressed
> N: alsa-sink.c: Increasing wakeup watermark to 40.00 ms
> N: alsa-sink.c: Increasing wakeup watermark to 80.00 ms
> Soft CPU time limit exhausted, terminating.
> E: cpulimit.c: Received request to terminate due to CPU overload
>
> It seems a configuration issue. Could you give some comments? thanks

Your sound driver is broken (as noted in the log messages above).

Some audio drivers do not implement snd_pcm_delay() and
snd_pcm_avail() correctly. e.g. intel-hda on some chips sometimes
overflows in snd_pcm_avail(). Since this call is used to determine how
much data PA must generate and write to the audio device an overflown
value usually means that PA will eat considerable CPU time to fullfill
humungous requests by the sound card. PA's CPU load limiter then
activates itself and terminates PA.

Also, as noted in log message the sound driver of yours very often
sets POLLOUT although there is nothing to write. That as well is a bug
in the sound driver. It causes PA to spin in its IO loop and results
on unnecessarily high CPU load.

Please make sure that your sound driver is fixed.

Also note the recent thread on alsa-devel about this.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss at mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
---

Richard