Causes a deadlock when the pulseserver dies

[sjoerd]

If the pulseserver dies the sinks _write calls GST_ELEMENT_ERROR inside a section with the pulseaudio mainloop mutex locked.. GST_ELEMENT_ERROR locks the element

The _reset function is called with the element locked and wants to lock the the mainloop mutex..

So one thread locks A, B and the other B, A.. Obvious deadlock ensues :(

[coling]

Just for completeness this does not require pa to "die", the stream just needs to be terminated (e.g. via pavucontrol) to deadlock the application - tested here with rhythmbox.

I think this may also be causing some applications to "go into a memory/cpu cyle eating loop". I've seen problems with e.g. gnome-power-manager and pidgin when I've had to kill PA or the streams after a resume form STR where the alsa driver has hiccuped and not allowed me to play sounds. Reloading the alsa driver "fixes" it but to do so I have to kill PA as it's "hogging" the device due to some frozen gstreamer streams.

Gstreamer streams seem to just sit there when the pa server gets into this state but e.g. paplay will play and quit as usual.

[slomo]

As gst-pulse has now moved to gst-plugins-good the bug is now here: http://bugzilla.gnome.org/show_bug.cgi?id=537540