GNOME Bugzilla – Bug 571204
[pulsesink] PA assertion failure triggers abort
Last modified: 2009-02-13 17:21:29 UTC
Using pulseaudio >= 0.9.12: gst-launch-0.10 -v audiotestsrc ! pulsesink Setting pipeline to PAUSED ... /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0.GstPad:src: caps = audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)1 Pipeline is PREROLLING ... E: thread-mainloop.c: Assertion '!m->thread || !pa_thread_is_running(m->thread) || !in_worker(m)' failed at pulse/thread-mainloop.c:170, function pa_threaded_mainloop_lock(). Aborting. Note that the problem does not occur without -v Cause: gst_pulsesink_context_subscribe_cb issues a g_object_notify() on volume (from a PA thread), which makes (a verbose) gst-launch query the volume property, leading to a pa_threaded_mainloop_lock() from a PA (worker) thread, which is what the assert() does not like.
Created attachment 128460 [details] [review] Possible patch * Move property change notification to streaming/rendering thread.
I think we have to do this. I don't know if it means we won't get notifications in PAUSED, and if we don't whether it a) matters, b) if it matters, what can we do about it other than start another thread somewhere? In the meantime, let's commit this...
let's commit this with some FIXME FIXME... really, we ought to model our volume control notifications on the GstMixer interface, sending stuff on the bus and not with a signal at all.
commit 7756d37531ea48d1890363e8bda9b9872c771a9f Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Fri Feb 13 18:03:14 2009 +0100 pulsesink: Issue property change notification in streaming thread, rather than PA thread. pa_threaded_mainloop_lock() (a.o.) and by extension get_property should not be done from a PA thread, but the latter may occur as a result of a property change notification. Fixes #571204 (though current situation not ideal, e.g. post message rather than signal).