> > > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
