After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711816 - audiobasesrc: Avoid unnecessary configuration if caps don't change
audiobasesrc: Avoid unnecessary configuration if caps don't change
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal major
: 1.2.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-11 06:22 UTC by Thomas Roos
Modified: 2014-01-15 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
minimal example program (5.58 KB, text/plain)
2013-11-11 06:22 UTC, Thomas Roos
Details

Description Thomas Roos 2013-11-11 06:22:00 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.
Comment 1 Thomas Roos 2013-11-11 08:11:50 UTC
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
Comment 2 Jan Schmidt 2014-01-02 15:02:37 UTC
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)
Comment 3 Jan Schmidt 2014-01-02 15:21:09 UTC
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.
Comment 4 Thomas Roos 2014-01-15 14:11:00 UTC
thank you - we tested it - that fixed our issue!
Comment 5 Sebastian Dröge (slomo) 2014-01-15 14:18:18 UTC
Jan, should we backport this to 1.2?
Comment 6 Sebastian Dröge (slomo) 2014-01-15 14:21:12 UTC
Should probably be backported as it's a regression over 1.0 AFAIU
Comment 7 Sebastian Dröge (slomo) 2014-01-15 14:22:20 UTC
It already is, sorry for the noise. Fix will be in 1.2.3