GNOME Bugzilla – Bug 777915
adder, audiomixer: negotiation sometimes fails
Last modified: 2018-05-06 09:32:51 UTC
In Gstreamer version 1.10.2, on Fedora 25, the following pipeline fails to negotiate about five times in ten: gst-launch-1.0 \ fakesrc num-buffers=5 format=GST_FORMAT_TIME ! \ audio/x-raw,rate=96000,format=S16LE,channels=1,layout=interleaved ! \ audioresample ! \ adder name=mix ! fakesink \ fakesrc num-buffers=5 format=GST_FORMAT_TIME ! \ audio/x-raw,rate=48000,format=S16LE,channels=1,layout=interleaved ! \ audioresample ! mix. If I change the rates to be the same, the pipeline succeeds ten times out of ten. The "additional debug info" points to gstbasesrc.c(2950): gst_base_src_loop (): /GstPipeline:pipeline0/GstFakeSrc:fakesrc1: or fakesrc0:.
Is this new since 1.10.2? Can you get a debug log of a failing run?
Created attachment 344564 [details] debug log from failing case Debug trace of failure to negotiate, only INFO and higher messages.
I did not see the problem in version 1.8. The attached debug log has only INFO and above messages; including DEBUG messages makes the file 5,924,111 bytes long, which is too big to attach.
Please get a log with GST_DEBUG=6, and compress the resulting file with xz. That should be small enough then. Or alternatively upload it to dropbox or similar.
Created attachment 344566 [details] debug trace at level 6, compressed using xz
This a known issue, the negotiation around mixers such as adder/audiointerleave/audiomixer is racy. The solution is to add a capsfilter after the mixer. The problematic sequence is: 1. audioresample0 does a getcaps, gets rate=[1,MAX] 2. audioresample1 does a getcaps, gets rate=[1,MAX] 3. audioresample0 says "ok, no need to resample" 4. audioresample1 says "ok, no need to resample" 5. audioresample0 pushes caps event with rate=96000, configures the mixer 6. audioresample0 pushes caps event with rate=48000, fails In the case where it works, the first audioresample manages to set the caps before the second one does the getcaps, so it switches to resampling. The real longer term fix would be to add calls to the audio conversion/resampling library into the GstAudioAggregator base class used by audiomixer & audiointerleave.
I can confirm that the problem goes away with a capsfilter after the mixer. There is a similar problem with format: gst-launch-1.0 \ fakesrc num-buffers=5 format=GST_FORMAT_TIME ! \ audio/x-raw,rate=48000,format=F32LE,channels=1,layout=interleaved ! \ audioconvert ! audioresample ! \ adder name=mix ! \ fakesink \ fakesrc num-buffers=5 format=GST_FORMAT_TIME ! \ audio/x-raw,rate=48000,format=S16LE,channels=1,layout=interleaved ! \ audioconvert ! audioresample ! mix. This problem is also avoided by placing a capsfilter after the mixer. I assume your proposed fix to the mixers would also fix this problem.
Thanks for the bug report. adder is not going to get fixed, it's effectively deprecated. As Olivier said, there's a conceptual issue here that needs to be worked around by setting caps or by implementing conversions as per bug #773762. I'll hijack this bug for a floating-point-division-by-zero bug that the initial pipeline exposes when substituting adder for audiomixer: Thread 2 "mix:src" received signal SIGFPE, Arithmetic exception.
+ Trace 237635
Thread 140737294616320 (LWP 27253)
Why do you feel it necessary to hijack this bug? It isn't hard to create a new bug report. This bug report has value even if adder is "effectively depreciated" and the bug will not be fixed. It provides information for those who encounter the bug about an effective workaround. If it is indeed true that adder will not be fixed, then I would expect information about this limitation, along with its workaround, to go into the Gstreamer documentation, at which time this bug report will cease to have value.
That is unfortunately difficult, since what's called adder in recent GStreamer is a thin layer on top of audiomixer and what was released in the past won't be modified. I'm sorry to say, but with the time passing, this information won't be relevant.
John: I could've closed it and cloned it, sure, but this issue has been reported many times before so this seemed reasonable enough, sorry :) It's liveadder that's based on audiomixer. Adder is still based on collectpads.
Since the problem has been reported many times, I am surprised that the documentation of adder has not been updated to say that you need to use a capsfilter after the adder unless your application guarantees that all sources use the same sample rate and format.
You're right. I have added something about this to the adder and audiomixer docs now (will take a bit until it gets updated on the website).
(In reply to Tim-Philipp Müller from comment #8) > I'll hijack this bug for a floating-point-division-by-zero bug that the > initial pipeline exposes when substituting adder for audiomixer: This does not happen anymore
(In reply to Sebastian Dröge (slomo) from comment #14) > (In reply to Tim-Philipp Müller from comment #8) > > > I'll hijack this bug for a floating-point-division-by-zero bug that the > > initial pipeline exposes when substituting adder for audiomixer: > > This does not happen anymore In which version does it not happen? Running Fedora 27 I am still seeing it: gst-launch-1.0 fakesrc num-buffers=5 format=GST_FORMAT_TIME ! audio/x-raw,rate=96000,format=S16LE,channels=1,layout=interleaved ! audioresample ! adder name=mix ! fakesink fakesrc num-buffers=5 format=GST_FORMAT_TIME ! audio/x-raw,rate=48000,format=S16LE,channels=1,layout=interleaved ! audioresample ! mix. Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstFakeSrc:fakesrc1: Internal data stream error. Additional debug info: gstbasesrc.c(2939): gst_base_src_loop (): /GstPipeline:pipeline0/GstFakeSrc:fakesrc1: streaming stopped, reason not-negotiated (-4) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ...
It works fine for me in git master and the 1.14 branch, but fails with not-negotiated in 1.12.4. Please re-open if it still happens for you with a recent version, thanks!
Version 1.14.0, as distributed in Fedora 28, still fails. However, I was only able to get it to fail by including --gst-debug=*:5 after gst-launch-1.0, and then only about half the time.
Created attachment 371695 [details] log.gz I can confirm that it sometimes errors out with not-negotiated, log attached. Not sure why it fails, didn't look in detail
You're using adder still, and not audiomixer. With audiomixer this never fails here.
Be that as it may, this is still a bug and deserves to be fixed. If it cannot or will not be fixed, it should be documented so users are aware of the workaround.
It's a well-known issue with adder and is not fixable in adder and will not be fixed in adder, sorry. Please note the adder documentation: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-adder.html#gst-plugins-base-plugins-adder.description "Caps negotiation is inherently racy with the adder element."
Thank you for the pointer to the updated documetation. It recommends using audiomixer from gst-plugins-bad. I found audiomixer in gst-plugins-base and changed my test case to this, replacing adder with audiomixer: export GST_DEBUG_FILE=gstreamer_debug.txt gst-launch-1.0 --gst-debug=*:5 \ fakesrc num-buffers=5 format=GST_FORMAT_TIME ! \ audio/x-raw,rate=96000,format=S16LE,channels=1,layout=interleaved ! \ audioresample ! \ audiomixer name=mix ! fakesink \ fakesrc num-buffers=5 format=GST_FORMAT_TIME ! \ audio/x-raw,rate=48000,format=S16LE,channels=1,layout=interleaved ! \ audioresample ! mix. Running on Fedora 28, which includes Gstreamer 1.14.0, negotiation still fails about half the time. I will compress and attach the level 5 log.
Created attachment 371724 [details] level 5 debug log from failing audiomixer in version 1.14.0, compressed with xz
I can't seem to reproduce that here, but thanks for providing the debug log. Maybe you can also provide a GST_DEBUG=6 log, in case some information is missing in this one still? Will take a look later
This looks like a duplicate of bug #795397. This will be fixed in 1.14.1. Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository. *** This bug has been marked as a duplicate of bug 795397 ***