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
