Topology: DMIC: Reduce PCM capabilities to DMIC configuration

[singalsu]

This patch impacts topologies sof-apl-nocodec, sof-apl-da7219, and
sof-glk-da7219 those use the pipe-passthrough-capture macro for DMIC.

The PCM saple rate is limited to 48 kHz (was 8 - 192 kHz). The capture
channels count can be only PIPELINE_CHANNELS (was 1 - PIPELINE_CHANNELS).
This prevents corrupted audio capture that happens when DMIC topology
parameters and capture parameters differ. It happens because DMIC FIFOs
drop samples or add unwanted samples when the configuration does not match.

In sof-apl-nocodec topology the PIPELINE_CHANNELS is set to 2 that
matches the configuration.

Signed-off-by: Seppo Ingalsuo seppo.ingalsuo@linux.intel.com

[singalsu]

@cujomalainey @ranj063 Can you please review this patch. I'm not able to directly set you into reviewers list for this.

[singalsu]

@sofci Can you please fix the logging.h issue in CI SOFT build to avoid PRs to be rejected unnecessarily.

[juimonen]

if ci is building soft with docker (as with sof) someone needs to build new container with sof headers installed or modify the build script to install sof headers during sof build...

[cujomalainey]

Is this the CRAS specific pipeline? If it isn't then we don't need to change the rate. @lgirdwood said we will create pipes specifically for cras with our requested configurations. I may be wrong in this opinion, but I don't see why would need to force users to use exactly 2 mic channels (i.e. disabling mono.) The comments in the pipeline files have the terminology "using max N channels" so I don't think we should bind the lower bound on the pipeline unless we have a specific reason to do so.

[singalsu]

I tested with sof-apl-nocodec. Before this patch I could capture corrupted audio by 1) using non-48 kHz sample rate 2) by using less channels than max. With this patch only the working configured DMIC mode starts the capture. Though arecord starts with nearest supported sample rate so when I requested 32 kHz I got an OK 48 kHz recording.

In case 1) the FIFOs produce too much or too little data so the recording becomes "Mickey Mouse" or "bogey" and file length does not match capture duration. In case 2) the non-matching FIFO channels interleaving to WAV channels interleaving also creates a corruption effect with not matching duration. There can be also xruns.

The DMIC parameters chunk in topology must match with captured channels.There's macros MONO_PDM0_MICA, MONO_PDM0_MICB, STEREO_PDM0, STEREO_PDM1, FOUR_CH_PDM0_PDM1 to select various 1/2/4ch configurations.

So, to capture mono need to replace e.g. STEREO_PDM0 with MONO_PDM0_MICA. Min and max. channels in topology should be set in that case to 1.

I have an APL based device running CRAS here so I can check the impact partially here tomorrow though the digital microphones in it are broken or missing (I should open it and see what's the issue). I'll update here how it impacts sof-apl-da7219.

[cujomalainey]

Sounds like a pretty good reason to me to bind them. Looks good to me.

[ranj063]

@singalsu what happens in the case of SSP capture? Do we want to limit those to 48KHz alone too?

[singalsu]

I'd assume SSP capture similarly would fail if SSP configuration in topology and arecord rate and channels do not match with it. The pipeline pipe-volume-capture has this PCM capability.

PCM_CAPABILITIES(Passthrough Capture PCM_ID, `S32_LE,S24_LE,S16_LE', 48000, 48000, 2, PIPELINE_CHANNELS, 2, 16, 192, 16384, 65536, 65536)

So the sample rate is fixed there to 48 kHz but channels can be 2..PIPELINE_CHANNELS. Minimum is set to 2. If PIPELINE_CHANNELS would be e.g. 4. I'd assume 2ch capture might fail. However I don't have HW to try. Anyway since SSP capture uses different pipe they would be not impacted by this PR.

[juimonen]

I made #92, which might be useful for setting the pcm rate range...

[lgirdwood]

PR #92 looks like the solution after some further refinement.

[singalsu]

@lgirdwood I updated just this PR. There was no merge conflict after all but I fixed a typo in a comment talking about 4ch while the proposed setup is 2ch.