GNOME Bugzilla – Bug 349902
[LADSPA] implement sources
Last modified: 2013-08-17 20:07:01 UTC
Please describe the problem: When testing LADSPA plug-ins that only have a src pad, the pipeline never gets beyong prerolling. I have tested this with two elements: gst-launch-0.10 ladspa-logistic ! audioconvert ! alsasink gst-launch-0.10 ladspa-Roessler ! audioconvert ! alsasink I get: jono@forge:/sources/gstreamer/head/gst-plugins-good/ext/ladspa$ gst-launch-0.10 ladspa-logistic ! audioconvert ! alsasink (gst-launch-0.10:18277): GStreamer-CRITICAL **: gst_element_class_add_pad_template: assertion `gst_element_class_get_pad_template (klass, templ->name_template) == NULL' failed (gst-launch-0.10:18277): GStreamer-CRITICAL **: gst_element_class_add_pad_template: assertion `gst_element_class_get_pad_template (klass, templ->name_template) == NULL' failed Setting pipeline to PAUSED ... Pipeline is PREROLLING ... and... jono@forge:/sources/gstreamer/head/gst-plugins-good/ext/ladspa$ gst-launch-0.10 ladspa-Roessler ! audioconvert ! alsasink (gst-launch-0.10:18328): GStreamer-CRITICAL **: gst_element_class_add_pad_template: assertion `gst_element_class_get_pad_template (klass, templ->name_template) == NULL' failed (gst-launch-0.10:18328): GStreamer-CRITICAL **: gst_element_class_add_pad_template: assertion `gst_element_class_get_pad_template (klass, templ->name_template) == NULL' failed Setting pipeline to PAUSED ... Pipeline is PREROLLING ... At that point, it just hangs until I stop gst-launch with Ctrl-C. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
This is because these days, GStreamer pipelines tend to run with threads on the source elements. I'd really prefer for the ladspa elements to have nothing to do with threads, although taking input from multiple threads will probably have to happen at some point (it's currently not threadsafe). The proper solution, IMO, is for alsasink to activate itself in pull mode, thereby driving the pipeline. However this is currently unsupported. I'd suggest waiting, if possible, until alsasink supports pull-mode operation.
The source and sink ladspa plugins should extend basesrc and basesink respectively to maximise the pain/pleasure ratio.
Sink ladspa plugins aren't really useful; I wouldn't waste time on them. Src plugins are useful tho. Perhaps the ladspa base class needs to be a helper object instead, like mixers. Blah.
I just ran into this, still same behaviour. Does alsasink have the mentioned pull-mode now? Or is there another preferred solution? PS: bug should be moved to component -bad, since
Jon, what pipeline did you try? There is experimental pull mode in basesinks (add can-activate-pull=TRUE).
gst-launch-0.10 ladspa-logistic ! audioconvert ! alsasink gst-launch-0.10 ladspa-analogueOsc ! audioconvert ! alsasink gst-launch-0.10 ladspa-sinCos ! audioconvert ! alsasink All end being stuck in PREROLLING: [jon@jon-laptop jonnors-mypaint-clone]$ gst-launch-0.10 ladspa-analogueOsc ! audioconvert ! alsasink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... I'm thought I tried adding can-activate-pull=TRUE to alsasink and it gave the same result. But now I'm getting a segfault on each invokation. Sometimes it reaches "Pipeline is PREROLLING" and sometimes it doesnt: [jon@jon-laptop ~]$ gst-launch-0.10 ladspa-sinCos ! audioconvert ! alsasink can-activate-pull=TRUE Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ** (gst-launch-0.10:17964): CRITICAL **: gst_signal_processor_prepare: assertion `GST_SIGNAL_PROCESSOR_IS_RUNNING (self)' failed Caught SIGSEGV accessing address 0x38 Spinning. Please run 'gdb gst-launch 17964' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core. ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... ^C [jon@jon-laptop ~]$ gst-launch-0.10 ladspa-sinCos ! audioconvert ! alsasink can-activate-pull=TRUE Setting pipeline to PAUSED ... ** (gst-launch-0.10:17985): CRITICAL **: gst_signal_processor_prepare: assertion `GST_SIGNAL_PROCESSOR_IS_RUNNING (self)' failed Caught SIGSEGV accessing address 0x38 This is on current stable of gstreamer and plugins (bad+good+base). I will try to see if the issue persists in git version and file a new bug if that is the case.
Oh my. There is a lot of code missing in GstSignalProcessor. It basically never starts a task with a loop function. Thus sources never work. I am overhauling this currently.
Stefan did you finish that overhaul and is this bug ready to be closed now?
I only have a WIP patch. Main issue are sources with multiple outputs, as those won't work with basesrc/signalprocessor.
This bug has an assigned developer but has not received activity in almost a year. Is the assigned person still working on this ?
This is done.
Why obsolete? It was fixed in: commit 70e208d08e0330112260b1ea3503f50e203977a8 Author: Juan Manuel Borges Caño <juanmabcmail@gmail.com> Date: Fri May 3 11:34:34 2013 +0200 ladspa: improved port to gstreamer 1.0 Fixes: #698927
Fixed needs a milestone for release purposes (for our scripts), so if we don't know when/where exactly it's been fixed I mark it as obsolete so I don't have to go through it again when making releases later. Git says it's fixed in 1.1.1 so let's milestone to that then :)