I also don't see any case where we support 4 channels in any broadwell
machine driver?
It's the bdw-rt5650.c which only exists in chrome's 3.14 branch supporting Buddy
project. They submitted the machine driver but not yet merged.
https://patchwork.kernel.org/patch/11050985/
So again can you point me to an issue or existing backport that requires the
patch below. Not trying to be obtuse but we should only change older
platforms when there is evidence that a change is needed.
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.
