pulseaudio spams my sound card with noise until my ears bleed

this is the bt of pulseaudio when it spams my sound card

Can you also attach the output of pulseaudio -vvv when it goes nuts. Also what version is this? (NB Lennart, have you accidentally/deliberately removed the version field?)

(Sadly, I don't think this problem demands highest priority and severity levels: at least not until some more info indicates that it is indeed a huge problem! :))

by "attach the output of pulseaudio -vvv when it goes nuts", do you mean that when pulseaudio does this again, I should run a new instance of pulseaudio with the -vvv flags? Or do you mean my one-and-only running pulseaudio daemon should be started with the -vvv flags?

The version of pulseaudio is 0.9.10

Sorry I could have been a bit clearer above :)

If you kill the running instance and run a fresh daemon with -vvv args and capture this to a file or something. When it goes nuts again, try and include the relevant bits of the log to see what's going on when it gives up the ghost :)

tried doing what you asked, but I can't reliably reproduce this problem anymore with:

pulseaudio -vvv > log 2>&1

This might suggest that the logging is somehow delaying things long enough to avoid a race condition that normally occurs on my machine.

Yeah I know the feeling... really annoying to track down :(

What application does this happen with most reliably? It may help to know the client that causes it.... Could it be a GStreamer app perchance? (just a guess)...

I've had it happen with a variety of apps (sorry, wasn't very good about taking notes so far) but it has been 100% (or nearly) reliable with running moonlight against microsoft's silverlight test suite (unfortunately, the test suite is not public). anytime any video test ends, my speakers play a never-ending wail until I killall -9 pulseaudio... it also blocks any new alsa connections until pulseaudio is restarted, which means I cannot run the test suite on my machine (because there are multiple tests with audio).

it might be possible to reproduce against moonlight's public video tests (I don't see any reason it wouldn't be, just that I haven't actually checked), but currently even if I restart pulseaudio w/o -vvv, I'm not able to reproduce atm (the race condition has decided to play nice for now I guess).

What version of PA is this?

Could you please paste PA's syslog output?

Also, please consider increasing the debug level in /etc/pulse/default.pa by setting log-level=default.

As I mentioned above, I'm using 0.9.10 - there's nothing in syslog other than a 2 or 3 line message about pulseaudio starting up (same stuff you get if you start pulseaudio on the console without -vvv)

Anyways... just managed to lock pulseaudio up a minute ago (altho this may have been a bug in my own alsa-using code as I was goofing around with it and now pa is locked up). I'll attach the log anyway.

Something is causing PA's internal memory pool to run over. That happens usually when some client opens too many streams or suchlike. Such as a flash instance running amok.

PA should not be that easy to lockup. Maybe PA suspended access to an audio device due to idleness and then was unable to resume access again because some other client stole the device? if that's the case than you can unsuspend the device manually via "pacmd". Or just start to play another stream which will cause PA to auto-resume the device.

well, I launched a new app instance to try and play sound but it got an error:

*** PULSEAUDIO: Unable to connect: Timeout

I don't see how anything I was running could have stolen the alsa device, so I don't think that is at all a possibility.

Could you start via "pulseaudio -vvC" please? And then check with "ls" typo into the commando prompt that is shown what goes one when this lockup happens?

sure, but keep in mind that with logging enabled, the timings change enough that I don't get the race condition nearly as easily (as in, I've been trying to repro since within 5 minutes after coling asked me to try with -vvv up to about a minute before I posted my first comment today).

ok, n/m, that didn't take long... it's hung right now and spamming my sound card but the pulseaudio console is unusable (aka "hung") so I can't type "ls" like you asked.

now what?

Hmm, I have an idea what is wrong. The backtrace you posted earlier shows a deadlock that happens when the RT threads have more than 128 messages in the queue and din't find time to process them. This has been fixed a while back in git but has not been released in a version yet. Usually this is however a sign of an issue in the clients connecting to PA since they issue so many requests in such a short time frame. Could you please elaborate what client this is? It apparently goes through the ALSA compat layer, right? What's the usage pattern of the client? Does it create a lot of simultaneous streams? A lot of very short streams? Anything special?

Well, I've had this happen to me with various programs: flash, xine, pidgin, I think mplayer, definitely moonlight and probably others.

I can't speak for most of the above clients, but as far as moonlight is concerned, we create a new alsa context per media source and use the RW_INTERLACED mode. However, it's not like any of the times I've been able to reproduce this with moonlight being the only running app making any sound requests that there has ever been more than 1 media source playing at a single time. Usually I'm able to reproduce on the very first media source being played (typically hangs at the end).

I'm not sure how short qualifies as "short", but the shortest stream I've ever tried to play in moonlight is included in the bug report I filed called something like "pa can't play short audio streams" or some such (which is ~8k or so). The next shortest stream I've tried to play is a good 3 or 4 times larger than that one. So I guess we're not trying to play "short" streams nor "a lot of simultanious" streams. I can't think of anything special that we are doing either.