How to correct params_format on DPCM ?

How to correct params_format on DPCM ?

[Kuninori Morimoto]

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

Re: How to correct params_format on DPCM ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1106 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: How to correct params_format on DPCM ?

[Kuninori Morimoto]

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

Re: How to correct params_format on DPCM ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1665 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: How to correct params_format on DPCM ?

[Kuninori Morimoto]

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

Re: How to correct params_format on DPCM ?

[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

Re: How to correct params_format on DPCM ?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 780 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: How to correct params_format on DPCM ?

[Kuninori Morimoto]

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