[PATCH] ASoC: soc-pcm: fixup soc_pcm_params_symmetry()

Kuninori Morimoto kuninori.morimoto.gx at renesas.com
Fri Apr 16 02:15:58 CEST 2021


Hi Mark

Thank you for your feedback

> > 	symmetric_rate		: DAI_Link / CPU / Codec (B)
> > 	symmetric_channels	: DAI_Link / CPU / Codec (B)
> > 	symmetric_sample_bits	: DAI_Link / CPU / Codec (B)
> 
> Right, this is what I'd expect.

Yes, I agree

> > Does this issue had been happen since older versoin ??
> > 
> > 	# aplay 44100.wav
> > 	# aplay 44100.wav
> > =>	[kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: 44100 - 48000
> > 	[kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22

I confirmed. Unfortunately there was copy miss (= bug) on
soc_pcm_params_symmetry() (= A) which didn't check Codec.
But is back by (B).

	A: v5.7:  commit c840f7698d26 ("ASoC: soc-pcm: Merge for_each_rtd_cpu/codec_dais()")
	B: v5.12: commit 3a9067211122 ("ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()")

In total,
old - v5.6 (= Generation-1):

	symmetric_rate		: DAI_Link / CPU / Codec
	symmetric_channels	: DAI_Link / CPU / Codec
	symmetric_sample_bits	: DAI_Link / CPU / Codec

v5.7 - v5.11 (= Generation-2): (= because of bug by (A))

	symmetric_rate		: DAI_Link / CPU
	symmetric_channels	: DAI_Link / CPU / Codec
	symmetric_sample_bits	: DAI_Link / CPU / Codec

v5.12 - (= Generation-3): (= back by (B))

	symmetric_rate		: DAI_Link / CPU / Codec
	symmetric_channels	: DAI_Link / CPU / Codec
	symmetric_sample_bits	: DAI_Link / CPU / Codec

Because of these, Generation-1 / Generation-3 have DPCM issue
if it was..
	1) using .be_hw_params_fixup
	2) exchanged BE's rate

The issue is below. I didn't confirm but maybe same things happen
if .be_hw_params_fixup exchanged channels/sample_bits, I guess.

	# aplay 44100.wav
	# aplay 44100.wav
=>	[kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: 44100 - 48000
	[kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22
	...

> I think this is something that gets confused by DPCM breaking
> assumptions :/ .  Not sure if *ignoring* the dummy DAI is the best
> option though, the general way the dummy works is that it has extremely
> loose constraints so it ends up not restricting anything else it gets
> paired with but then the dummy DAI might end up in multiple links.

Ignoring dummy-DAI is not so bad idea,
and it is possible to lose any constraints, I think.
soc_probe_component() is also ignoring it.

	static int soc_probe_component(...)
	{
		...
=>		if (!strcmp(component->name, "snd-soc-dummy"))
			return 0;
		...
	}

> Is it a case of needing a fixup function, or special handling if a fixup
> function is there?

Above issue will gone if soc_pcm_params_symmetry() didn't check
dummy-DAI's rate/channels/sample_bits.
I will post the patches.

Thank you for your help !!

Best regards
---
Kuninori Morimoto


More information about the Alsa-devel mailing list