Question regarding use of interleaved and deinterleaved elements in processing chain

[Hauke Krüger]

On 08/23/2016 10:24 AM, Sebastian Dröge wrote:
> On Mon, 2016-08-22 at 21:15 +0200, Hauke Krüger wrote:
>>> You'll have to connect to the "pad-added" signal of it, and from there
>>> link the pads further. See also the first part in chapter 8 of the
>>> manual (application developer's manual).
>> Yes, that worked out as you said. However, it seems to be impossible to
>> set the pipeline into the
>> PLAYING state afterwards: Whenever trying to set the state of the
>> pipeline to PLAYING, the pipeline element
>> is blocked since it expects an ASYNC state change which unfortunately
>> never really is solved.
>>
>> How is that part supposed to work? Is there any way to somehow observe
>> the ASYNC state change by catching
>> a message in the main loop?
> That all depends on your actual pipeline. How does it look like?
>
> Most commonly this means that you have one or more sinks in your
> pipeline that never receive any buffer and are async=true (which is the
> default). You should check where data flows in your pipeline and why it
> doesn't reach all sinks. Also check if you get any error messages.
>
>

My pipeline is rather simple:

alsasrc -> capsfilter -> deinterleaver -<channel0>-> interleaver -> 
capsfilter -> alsasink
-<channel1>->

alsasrc and alsasink are configured to allow 2 channels, no rate 
conversion must be
done.

I tracked the problem by means of my debugger: once all pads are 
connected, I can see
the deinterleaver working: It has 2 output sources and I can see the 
code in which the deinterleaver
loops over all sources here: deinterleave.c, line 896 (current master 
release of gstreamer 1.0 project).
I see that the function "gst_pad_push" is used within the loop to pass 
the single buffers to the connected
interleaver sink.

When debugging into this function call of "gst_pad_push" for the first 
single buffer to be transferred, I end
up in "gstcollectpad.c" since the interleaver seems to use this 
collector block. The buffers seem to arrive
in  function "gst_collect_pads_chain" to wait for all buffers before 
interleaving takes place.

Debugger shows that the first buffer is accepted but the program flow 
ends in a non-returning wait condition
in line 2257 in "gstcollectpad.c",

/* wait to be collected, this must happen from another thread triggered
      * by the _chain function of another pad. We release the lock so we
      * can get stopped or flushed as well. We can however not get EOS
      * because we still hold the STREAM_LOCK.
      */
     GST_COLLECT_PADS_STREAM_UNLOCK (pads);
     GST_COLLECT_PADS_EVT_WAIT (pads, cookie); <---- HERE
     GST_COLLECT_PADS_STREAM_LOCK (pads);

It seems that the wait will persist locked until the chain function is 
called from within the context of another thread.

This behavior would make sense if the deinterleaver would decompose the 
single buffers to be
processed within different thread contexts. This, however, seems not to 
be the case.

Do I miss to set a specific property to tell the interleaver that it 
shall not be in wait mode? Or is there another trick which
I would need to employ?

Thank you and best regards

Hauke