[alsa-devel] How to correct params_format on DPCM ?
Hi Mark, Lars, all
Now, I'm using DPCM based sound, but FE/BE gets different params format. How to correct it ? This sound can be used both non-DPCM card / DPCM card
-- non-DPCM card -- cpu: rsnd codec: ak4642
-- DPCM card -- FE : cpu: rsnd codec: snd-soc-dummy
BE : cpu: snd-soc-dummy codec: ak4642
Here, SNDRV_PCM_FMTBIT_S16_LE is always selected on non-DPCM card. This is OK.
rsnd: SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S16_LE ak4642: SNDRV_PCM_FMTBIT_S16_LE
On DPCM card, FE gets S24, BE gets S16 if aplay selects S24 wav. But, FE needs S16, same as non-DPCM card. I know we can fixup BE side via dai_link.be_hw_params_fixup, but this is FE side.
It can't use correct sound playback in corrent DPCM card. But, how to solve this issue ??
Best regards --- Kuninori Morimoto
On Tue, Apr 07, 2015 at 05:05:34AM +0000, Kuninori Morimoto wrote:
Here, SNDRV_PCM_FMTBIT_S16_LE is always selected on non-DPCM card. This is OK.
rsnd: SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S16_LE ak4642: SNDRV_PCM_FMTBIT_S16_LE
On DPCM card, FE gets S24, BE gets S16 if aplay selects S24 wav. But, FE needs S16, same as non-DPCM card. I know we can fixup BE side via dai_link.be_hw_params_fixup, but this is FE side.
It can't use correct sound playback in corrent DPCM card. But, how to solve this issue ??
I'm not sure what exactly was intended here but this seems to need fixing in the core - I think the assumption in the DPCM code is that the sort of hardware that uses it will have rewriting support that makes the back end constraints irrelevant to the front end. I think what we want here is some way to signal to the framework that the front end constraints aren't used and it should use the back end ones instead - perhaps just omit the constraints that aren't rewritten and then have the framework take those from the backend instead.
Hi Mark
rsnd: SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S16_LE ak4642: SNDRV_PCM_FMTBIT_S16_LE
(snip)
I'm not sure what exactly was intended here but this seems to need fixing in the core - I think the assumption in the DPCM code is that the sort of hardware that uses it will have rewriting support that makes the back end constraints irrelevant to the front end. I think what we want here is some way to signal to the framework that the front end constraints aren't used and it should use the back end ones instead - perhaps just omit the constraints that aren't rewritten and then have the framework take those from the backend instead.
Now I'm debuging about this issue, but it is very complex. I need your help. where should I check/debug ?
My problem is...
In non-DPCM case
cpu : rsnd : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE codec: ak4642: SNDRV_PCM_FMTBIT_S16_LE ----------------------------------------- SNDRV_PCM_FMTBIT_S16_LE is used, this is OK
In DPCM case
FE cpu : rsnd : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE FE codec: dummy : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | ...
BE cpu : dummy : SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE | ... BE codec: ak4642: SNDRV_PCM_FMTBIT_S16_LE
SNDRV_PCM_FMTBIT_S24_LE is used on FE, SNDRV_PCM_FMTBIT_S16_LE is used on BE. this means FE send S24 data, but BE can't use it.
Which function/method controls format ? I guess it is doning some kind of
format = cpu->formats & codec->formats;
DPCM case need to care about FE/BE, and maybe this is lost item.
format = fe_cpu->formats & fe_codec->formats & be_cpu->formats & be_codec->formats;
I guess it is done before hw_param() (?), or snd_soc_instantiate_card() timing. but I couldn't find it. It is very confusable/complex. which function is doing this ?
Best regards --- Kuninori Morimoto
On Fri, Apr 10, 2015 at 07:12:28AM +0000, Kuninori Morimoto wrote:
I'm not sure what exactly was intended here but this seems to need fixing in the core - I think the assumption in the DPCM code is that the sort of hardware that uses it will have rewriting support that makes the back end constraints irrelevant to the front end. I think what we want here is some way to signal to the framework that the front end constraints aren't used and it should use the back end ones instead - perhaps just omit the constraints that aren't rewritten and then have the framework take those from the backend instead.
Now I'm debuging about this issue, but it is very complex. I need your help. where should I check/debug ?
I think you're going to need to implement some new code.
Which function/method controls format ? I guess it is doning some kind of
format = cpu->formats & codec->formats;
DPCM case need to care about FE/BE, and maybe this is lost item.
format = fe_cpu->formats & fe_codec->formats & be_cpu->formats & be_codec->formats;
I guess it is done before hw_param() (?), or snd_soc_instantiate_card() timing. but I couldn't find it. It is very confusable/complex. which function is doing this ?
My point is that it's not happening and you're going to need to add that support. It's slightly more complex than your picture as most things that do DPCM can rewrite the format so we normally don't want to constrain with the back end constraints. Like I said in my eariler reply I think we want to change things so that if there's no front end constraint we take the back end one instead.
Hi Mark
format = fe_cpu->formats & fe_codec->formats & be_cpu->formats & be_codec->formats;
I guess it is done before hw_param() (?), or snd_soc_instantiate_card() timing. but I couldn't find it. It is very confusable/complex. which function is doing this ?
My point is that it's not happening and you're going to need to add that support. It's slightly more complex than your picture as most things that do DPCM can rewrite the format so we normally don't want to constrain with the back end constraints. Like I said in my eariler reply I think we want to change things so that if there's no front end constraint we take the back end one instead.
Thank you for your feedback. I try this idea.
Best regards --- Kuninori Morimoto
Hi Mark, Lars again
format = fe_cpu->formats & fe_codec->formats & be_cpu->formats & be_codec->formats;
I guess it is done before hw_param() (?), or snd_soc_instantiate_card() timing. but I couldn't find it. It is very confusable/complex. which function is doing this ?
My point is that it's not happening and you're going to need to add that support. It's slightly more complex than your picture as most things that do DPCM can rewrite the format so we normally don't want to constrain with the back end constraints. Like I said in my eariler reply I think we want to change things so that if there's no front end constraint we take the back end one instead.
In my debug, I guess key function is dpcm_init_runtime_hw() But, I would like to know about concept about this.
If my understanding is correct, the information which userland can get is setuped in .open
In non-DPCM case
soc_pcm_open() - soc_pcm_init_runtime_hw() /* setup runtime->hw */
In DPCM case
dpcm_fe_dai_open() - dpcm_fe_dai_startup() - dpcm_be_dai_startup() - soc_pcm_open() /* don't care runtime->hw */ - soc_pcm_open() /* don't care runtime-hw */ - dpcm_set_fe_runtime() - dpcm_init_runtime_hw() /* setup runtime->hw */
I guess my issue will be solved if I added code here which cares BE. But, I wounder non-DPCM case, runtime->hw has cpu/codec merged information in soc_pcm_init_runtime_hw(). But, DPCM cases, it cares only cpu information. why it doesn't care codec ?
If my understanding was correct, corrent image is...
non-DPCM hw = cpu & codec
DPCM hw = fe_cpu
I guess DPCM should be...
FE.hw = fe_cpu & fe_codec BE.hw = be_cpu & be_codec
And, if no FE constraint, final image will be
hw = FE.hw & BE.hw
But, am I misunderstanding ?
Best regards --- Kuninori Morimoto
On Mon, Apr 13, 2015 at 04:54:39AM +0000, Kuninori Morimoto wrote:
If my understanding is correct, the information which userland can get is setuped in .open
Yes.
But, DPCM cases, it cares only cpu information. why it doesn't care codec ?
Like I said before for most systems that do DPCM (and certainly the ones Liam's been working on) there's a DSP in place which rewrites all the data between the front end and the back end so the constraints of the CODEC aren't visible to the application layer.
I guess DPCM should be...
FE.hw = fe_cpu & fe_codec BE.hw = be_cpu & be_codec
Usually there's nothing "CODEC" visible at the front end for these systems.
And, if no FE constraint, final image will be
hw = FE.hw & BE.hw
Well, BE and CODEC but probably.
Hi Mark
Thank you for your feedback
I guess DPCM should be...
FE.hw = fe_cpu & fe_codec BE.hw = be_cpu & be_codec
Usually there's nothing "CODEC" visible at the front end for these systems.
Wow !
And, if no FE constraint, final image will be
hw = FE.hw & BE.hw
Well, BE and CODEC but probably.
OK, I will re-consider about this again
Best regards --- Kuninori Morimoto
participants (2)
-
Kuninori Morimoto -
Mark Brown