GNOME Bugzilla – Bug 382194
Adding LADSPA effects while playing causes static audio
Last modified: 2013-08-21 17:57:51 UTC
In Jokosher we add LADSPA effects (using the 'ladspa') element while in PLAYING. As each effect is added, static can be heard with each effect that is added. If the pipeline is stopped and sent to PLAYING again, the static is gone, so it seems to be a problem *while* the audio is flowing in PLAYING. This can be demoed with the following steps in Jokosher: 1. Add an instrument and right-click and import audio. 2. Press play. 3. Click the effects button on the instrument header, select an effect from the combo and click the Add button. The effect is added and the static is heard. wtay thinks this may be a problem with the ladspa element or maybe the adder.
Created attachment 77624 [details] python-gst test that inserts a ladspa element into the pipeline when it is playing Just replace the two variables at the top of the file with a media file path and a ladspa element name that is installed on your system. Then run the script.
This basically caused by Bug #339795. I don't understand how ladspa can accept the int caps, though.
As bug #339795 is fixed now, can we close this bug too?
There is still a bug somewhere. If I run the attached script (after changing the sample audio file), audio stops when the ladspa-fx is inserted. With some debug logging enabled I can see that there is a caps issue: 0:00:05.332336178 21010 0x80af510 DEBUG GST_CAPS gstpad.c:1876:gst_pad_link_check_compatible_unlocked: caps are compatible 0:00:05.333134725 21010 0x87f9b00 DEBUG GST_CAPS gstpad.c:2776:gst_pad_configure_sink:<ladspa-decimator0:Input> caps audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2 not accepted 0:00:05.333187741 21010 0x87f9b00 WARN baseparse gstbaseparse.c:2733:gst_base_parse_loop:<mpegaudioparse0> error: streaming stopped, reason not-negotiated 0:00:05.333267066 21010 0x87f9b00 DEBUG GST_CAPS gstpad.c:2776:gst_pad_configure_sink:<ladspa-decimator0:Input> caps audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2 not accepted The example works if I use e.g. "volume" or "equalizer-3bands" instead of the ladspa-element. Its a good test though, as it also fails with other elements (audioecho, pitch, ...)
Can someone still reproduce this with latest GIT master? This should work just fine now because of the reconfigure events that are send when re-linking elements. However the insertion of the filter here should happen from a pad probe, not just at some point when data might be flowing. I'm closing this as obsolete for now unless someone can reproduce it.