recording since this machine does not support it in the beginning.
The story is Chrome has a tool called alsa_conformance_test which runs
capture or playback against a PCM port with all possible
configurations (channel, format, rate) then measure if the sample rate
is correct. Since the channel max number reported is 4, it tests the
4-channel 48K capture and reports the actual sample rate is 24000
instead of 48000. That's the reason we want to add a constraint in
machine driver to avoid user space programs trying to do 4 channel
ok, that helps get context, thanks for the details.
I would have expected some error to be returned if there's a front-end
opened with 4 channels and the back-end only supports two. Adding the
constraint seems like a work-around to avoid dealing with the mismatch
between FE and BE. I don't understand DPCM enough to suggest an
alternative though. Ranjani, can you help on this one?
And even if we agree with this solution, it'd be nice to apply it for the
Broadwell machine driver for consistency.
It's not only the mismatch but also the design limitation. According to the
information from google, the board (samus) only uses two microphone so
3 or 4 channel recording are not supported. That's the reason we leverage
the constraint from other machine driver (like kbl_da7219_max98357a.c)
to remove the 3 and 4 channel recording option.
The difference after the constraint is implemented is that the
snd_pcm_hw_params_set_channels() function will return error (Invalid
argument) when channel number is 3 or 4 so the application knows the
configuration is not supported.