We are using a professional audio card to record from 8 channels. It's a very specific use cases so they are really 8 independent channels recorded altogether. We deinterleave and process them separately.

Problem is, alsasrc handles them as a 7.1 setup and does some reordering when capturing which is not what we want. Here is what happens:

When detecting which channels configuration is supported by the sound card, gstalsa.c:caps_add_channel_configuration() assumes that having 8 channels means 7.1 audio and so set it as channel-mask on the caps. This behavior is hard coded.

Later when gst_audio_ring_buffer_set_channel_positions() is called it checks if the channel positions of the stream (which has been derived from the channel-mask using gst_audio_channel_positions_from_mask()) matches the channel positions of ALSA (the alsa_positions array defined in gstalsa.c).
As the stream claimed to be 7.1 and as the ALSA channel ordering is different from the GST ordering, a reordering map is generated using gst_audio_get_channel_reorder_map() and samples are reordered by alsasrc.

This breaks things with our hardware as the 8 channels are really independents and so don't have any specific position.
A simple hack disabling re-ordering in gst_audio_ring_buffer_set_channel_positions() workarounds the problem for us but we'd like to fix this properly upstream.

I think the proper way to fix this would be to read the channel positions from ALSA (cf https://www.kernel.org/doc/Documentation/sound/alsa/Channel-Mapping-API.txt ) but I'm not sure of the right way to use this info.

caps_add_channel_configuration() could use it to set the proper channel-mask. In this case, the driver would say that all channels are independents (8 SNDRV_CHMAP_MONO) and gst would turn this to channel-mask=0. Then the audioringbuffer could check in gst_audio_ring_buffer_set_channel_positions() if the stream position is composed only of GST_AUDIO_CHANNEL_POSITION_NONE and don't do any reodering in this case.
GST_AUDIO_CHANNEL_POSITION_NONE is defined is the doc as "used for position-less channels, e.g. from a sound card that records 1024 channels; mutually exclusive with any other channel position" so that seems to be what we want here.

But I'm wondering if gst_audio_ring_buffer_set_channel_positions() shouldn't also use the channel positions returned by alsa instead of the hardcoded alsa_position array. In this case gst_audio_ring_buffer_set_channel_positions() shouldn't be modified as both array will then be equals (8 GST_AUDIO_CHANNEL_POSITION_NONE).

Of course we'll have to keep the existing code path for old drivers not implementing ALSA's channel mappings API.

I didn't check in details but I think the same problem may arise with alsasink as the code paths are pretty symetric.