RE: [alsa-devel] [PATCH] ASoC: bdw-rt5677: channel constraint support

[Lu, Brent]

> >
> > 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
> recording since this machine does not support it in the beginning.
> 
> 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.


Regards,
Brent