"hot-linking" audioecho into pipeline results in silence for a period

[Stefan Sauer]

On 01/10/2015 04:52 PM, Charlie FG wrote:
> On 09/01/15 19:52, Stefan Sauer wrote:
>> On 01/09/2015 12:37 AM, Charlie FG wrote:
>>> I place 'audioecho' element (already linked between two 'audioconvert'
>>> elements) into the pipeline but 3500 milliseconds after it has switched
>>> to PLAYING ... It does work but with a major drawback - there is silence
>>> for ~3500ms (once the 'queue' has expended it's buffers). If I change
>>> the time of the hot-linking event to, say, 12000ms it will be silent for
>>> ~12000ms; once it has seemingly caught up, it will play from the point
>>> the 'audioecho' was linked in, with the echo active.
>> It's an filter element that does transform inplace - that is the output
>> buffers have the same metadata is the inputs. Is your code public,
>> seeing it might help, this sounds a bit like as if the new elements are
>> not properly setup in terms of the playback segment.
>>
>> Stefan
> Stefan,
>
> First, thank you very much for your time!
>
> For quick reference - a PipeSegment is a collection of elements to be
> put into a Pipeline. The Pipeline is acting as an abstraction of
> GstPipeline. The PipeSegments share the common GstPipeline held in the
> Pipeline object they added to.
>
> Here is the main flow so you don't have to waste time hunting around in
> the repo for the bits and bobs.
>
> ---
>
> The setup of the initial pipeline is in loadplay.cpp, from line 32
> After the event is triggered, it tells the Pipeline to insert a new
> 'effects' PipeSegment on 64
> (The effects PipeSegment is defined on line 97
>
> https://github.com/carrotsrc/rackoonIO/blob/master/gst/loadplay.cpp
>
> ----
>
> The insertion jumps to Pipeline.cpp, Pipeline::insertSegment() on line
> 26. Here is where the blocking probe is added.
>
> https://github.com/carrotsrc/rackoonIO/blob/master/gst/lib/Pipeline.cpp
>
> ---
>
> Once the probe is added, it jumps to AudioEvents.cpp into the only
> function in there. Here is where it
> * sets the new elements' state to PLAYING (19)
> * adding the new elements to the bin + linking them together (22)
> * unlinking of the two surrounding elements (24)
> * linking new elements into pipeline (26,29)
> * removing pad
>
> https://github.com/carrotsrc/rackoonIO/blob/master/gst/lib/AudioEvents.cpp
A tiny suggestion - instead of
gst_pad_remove_probe (pad, GST_PAD_PROBE_INFO_ID (info));

	free(data);

	

	cout << "~~~Hotlinking" << endl;

	GST_INFO("RackoonIO Event: ~Hotlinking");

	return GST_PAD_PROBE_OK;

just return GST_PAD_PROBE_REMOVE;
In my app, I first link and then set the new elements to PLAYING. But
for effects this should not make much of a difference. Also as one
tricky part - I query the current upstream playback position and also
send a seek to sync the new elements, I think that this is not needed
anymore though.

Stefan

>
> ---
>
> The issue may be compounded by my making it semi-oop without
> properly understanding Gstreamer ;)
>
> Charlie
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150110/d23137d0/attachment-0001.html>