Question regarding use of interleaved and deinterleaved elements in processing chain

[public-hk at ind.rwth-aachen.de]

Am 25.08.2016 um 08:58 schrieb Sebastian Dröge:
> On Wed, 2016-08-24 at 22:03 +0200, public-hk at ind.rwth-aachen.de wrote:
>>> That's exactly the problem: you have to put a queue element after
>>> each deinterleave pad for adding this new thread.
>>  
>> Thank you, that was the trick I was looking for ;-)
>>
>> For those who will run into the same problem: If you connect the
>> interleaver to alsasink, you will
>> in addition need to provide a channel mask by setting the property
>> "channel-positions" properly.
>> Otherwise, the interleaver will not connect to alsasink.
>> And if you set that property, you will need to link against the
>> gstreamer-audio library in order to set the
>> correct GValue type (type GST_TYPE_AUDIO_CHANNEL_POSITION).
> You can also let it use the channel position of the input btw.
>
> Instead of interleave you might also want to use audiointerleave, which
> is the new version of the element and generally works better.

>From what I observed with the debugger, the following seems to be the
strategy:

If letting the channel positions empty and setting the option
"channel-positions-from-input" to true (the default),
the module uses a NULL/empty channel configuration.
The channel-mask which is filled in the caps automatically on caps
fixation is 0x0000000 in this case.
The alsasink, however, specifies the channel-mask as 0x00000003 given,
e.g., a stereo output. That
prevents the interleaver to connect with the alsasink in my case.

Depending on the number of channels, different channel-positions must be
specified since this is what alsasink expects.

If using more than 8 channels, the alsasink also sets the channel-mask
to 0x0000000 since channel positions are not defined for this
number of channels. In that case, there is no need to set the channel
positions and interleaver connects with alsasink.

>
>> And finally: we have a soundcard running which has 196 channels. The
>> interleave gstreamer plugin has a limitation
>> to expect a maximum of 64 channels only: In line 63 of interleaver.h,
>> the limitatin is given as
>>
>> gint default_channels_ordering_map[64];
>>
>> By connecting 196 channels, this limit does not really stop the
>> interleaver from returning requested pads as it seems.
>> But it will cause a segmentatin fault later. Setting the 64 to 196
>> solved this problem. The same modification maybe done in line 275 in
>> file interleave.c. But I have to admit those 196 channels are really
>> an unexpected hardware setting.
> We currently only have support for 64 positioned channels, but more
> unpositioned should be useful and relatively easy to support.
>
> Do you want to provide your patch? Instead of making the array bigger,
> for > 64 channels you would use an unpositioned layout
> (GST_AUDIO_CHANNEL_POSITION_UNPOSITIONED) and can leave the array
> empty.
>
>

It might be a clean way to introduce a global configuration variable for
gstreamer to set the
maximum number of allowed channels at a central position since also the
alsa plugin 
has a limitiation of channels to a number of 8 given that users open a
plughw device.
For my 196 channels, I had to increase the number of channels at
multiple positions.
By introducing a global variable (e.g. a global define), this aspect
would be clear from the beginning
and might be adapted if installing the gstreamer lib manually. If I
modify the max value from
64 to 256 (my current solution), the next soundcard may have 384
channels ;-)

Best regards

Hauke