GNOME Bugzilla – Bug 711816
audiobasesrc: Avoid unnecessary configuration if caps don't change
Last modified: 2014-01-15 14:22:20 UTC
Created attachment 259521 [details] minimal example program I am using an input-selector element to select one of two microphone inputs delivered as a stereo stream by alsasrc. This worked fine in Gstreamer 0.10.36, but seems to be broken in Gstreamer 1.2.0. After switching the sink of the input-selector, the pipeline produces silence for some time (running-time of pipeline ?) until finally the live data are to be heard again. The behaviour can be reproduced with the minimal program attached, which produces 5sec of silence after switching. Everything works as expected when alsasrc is replaced by a 2*testsrc/interleave combo.
http://lists.freedesktop.org/archives/gstreamer-devel/2013-November/044139.html Q: I assume it fails the same way if you use audiotestsrc with is-live=true? A: no if you use audiotestsrc it works as expected
The root of this problem is that changing pads now triggers a reconfigure event upstream from input-selector, which makes the audiobasesrc reevaluate the caps, releasing and acquiring the ringbuffer in the process. Reverting 587b2721c876ca70b16f568c0ce12d8675d606ca from bug # 697723 makes this case work again, albeit with glitches at the switching due to alsasrc reconfiguring itself that way (unnecessarily, since the caps don't actually change)
bug # 720692 also relates to this problem, but the patch there doesn't fix anything. What does help somewhat is to ignore the spurious caps change in baseaudiosrc. baseaudiosink already does that. I'll change that at least: commit f0b655e1ad2af1d1d6c1944a63e1b7040c1e0251 Author: Jan Schmidt <jan@centricular.com> Date: Fri Jan 3 02:18:20 2014 +1100 audiobasesrc: Avoid unnecessary configuration Port a change from audiobasesink from def07410, to ignore setcaps when the caps don't actually change, and avoid a reconfiguration and reset of the ringbuffer in that case.
thank you - we tested it - that fixed our issue!
Jan, should we backport this to 1.2?
Should probably be backported as it's a regression over 1.0 AFAIU
It already is, sorry for the noise. Fix will be in 1.2.3