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