ALSA / ringbuffer chmap reorder issue
In a setup where an ALSA device exists with two channels and chmap with FL and FR. A simple ALSA plug will make it possible to play mono audio directly. In this setup, gstreamer will end up in critical print in gstaudioringbuffer that depending options also may core dump.
One can see that the media in buffer is mono but the map received from ALSA only has FL:
(gdb) p buf->spec
$9 = {
info = {
finfo = 0xb6aaef50 <formats+256>,
flags = GST_AUDIO_FLAG_NONE,
layout = GST_AUDIO_LAYOUT_INTERLEAVED,
rate = 48000,
channels = 1,
bpf = 2,
position = {GST_AUDIO_CHANNEL_POSITION_MONO, GST_AUDIO_CHANNEL_POSITION_INVALID <repeats 63 times>},
_gst_reserved = {0x0, 0x0, 0x0, 0x0}
}, ...
(gdb) p position[0]
$10 = GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT
Having mono as one of the channels will return for the critical print in audio-channels
So, if only having one channel and the bufer comes in MONO, should we really end up here or is the ALSA plug misconfigured? A fix in gstreamer code could be if having only one mono channel in buf, skip trying to reorder?
Simplified way to reproduce:
gst-launch-1.0 filesrc location=/dev/zero ! audio/x-raw,layout=interleaved,format=<correct format>,rate=<correct rate>,channels=1 ! alsasink device=plug:<stereo alsadevice>