GNOME Bugzilla – Bug 114331
[threads] scheduler should not schedule PAUSED elements
Last modified: 2005-10-11 14:22:44 UTC
It seems that scheduler is scheduling element that are in PAUSED state.. For example if you try to play an audio file while xmms is playing through oss at the same time. You will receive thousands of "error" signal from pipeline with error message "osscommon: Unable to open /dev/dsp (in use ?)" osssink was not able to switch to READY but it gets scheduled and i m flooded by error messages. Benjamin thinks it's a scheduler issue.. We would need to fix that for 0.6.2 !
There is another issue with this that is quite fundamental: Some plugins seek back if they receive an EOS (bug 111498 is an example of this - maybe two-pass encoding, too?) An EOS makes plugins go to PAUSED however so they might not be scheduled after that. To fix that I can imagine 2 possibilities: - Create a new state GST_STATE_EOS (ugly but makes sense, plugins might behave differently when going to EOS than when going to PAUSED - alsa for example drains the audio buffer and stops on EOS while it immediately pauses when going to PAUSED, i had to special case there) This is my preferred idea - Allow plugins to set themselves to PLAYING when receiving events. This is ugly somehow because state changes are something explicit and shouldn't be triggered by weird stuff like seek events.
Isn't that totally unrelated to this, Benjamin? And I'm not much in favour of introducing a new state, I'd rather fix broken plugins. :).
an EOS event on a plugin only makes that plugin go to PAUSED if the plugin want that to happen (with gst_element_set_eos or when using the default event handler gst_pad_event_default), an example of such a plugin is mikmod and sidplay. The scheduler should not schedule PAUSED elements and I doubt that it does, I'm betting spider is trying to change the state of the osssink repeadedly (as that's what triggers osssink to open the device)
As a side note, it is not the scheduler that is scheduling a paused element, it's an upstream PLAYING element that pushes a buffer to a chained PAUSED element. The scheduler still has the ability to stop this, but it doesn't.
Ronald pointed me to this. I have pipelines like e.g. two sines connected to an volume each, then to an adder and that to a audio_sink. When setting one sine to pause it continues to play. Pausing the volume works though. The gst_element_set_state() reports no problem.
Created attachment 36455 [details] gst-editor network to simulate the error set the pipeline to playing and then one sinesrc to paused
This may also be simulated using the testcase in #165928.
Changing version to 0.8.x. Retargeting to 0.8.x too.
Obsolete, this does not apply to 0.9, and I doubt anyone will fix it for 0.8.