[alsa-devel] Question about DPCM FE vs BE

[alsa-devel] Question about DPCM FE vs BE

[Kuninori Morimoto]

Hi ALSA ML

In my understanding, DPCM needs FE and BE.
And, one FE can have multiple BE, and one BE can have multiple FE.

My question this time is that one snd_soc_pcm_runtime can be both
FE and BE in the same time (= Sometimes FE, sometimes BE) ??

In my understanding, it never happen.
But, is this correct ?

I'm asking because do we need .be_clients/.fe_clients ?
If one pcm_runtime can't be FE / BE in the same time,
just .clients is enough I think.

	static int dpcm_be_connect(...)
	{
		...
-		list_add(&dpcm->list_be, &fe->dpcm[stream].be_clients);
-		list_add(&dpcm->list_fe, &be->dpcm[stream].fe_clients);
+		list_add(&dpcm->list_be, &fe->dpcm[stream].clients);
+		list_add(&dpcm->list_fe, &be->dpcm[stream].clients);
		...
	}


Thank you for your help !!
Best regards
---
Kuninori Morimoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about DPCM FE vs BE

[Pierre-Louis Bossart]

On 10/9/19 2:57 AM, Kuninori Morimoto wrote:
> 
> Hi ALSA ML
> 
> In my understanding, DPCM needs FE and BE.
> And, one FE can have multiple BE, and one BE can have multiple FE.
> 
> My question this time is that one snd_soc_pcm_runtime can be both
> FE and BE in the same time (= Sometimes FE, sometimes BE) ??
> 
> In my understanding, it never happen.
> But, is this correct ?

It is my understanding that the current code would not support a case 
where a FE is also a BE.

That said, do we want to preclude it? at some point we probably want to 
get rid of the FE/BE distinction and have 'domains' that can be chained. 
So it may not be a good thing to cast a restriction in stone. If at some 
point we need a list of upstream/downstream clients maybe we should keep 
this.

> 
> I'm asking because do we need .be_clients/.fe_clients ?
> If one pcm_runtime can't be FE / BE in the same time,
> just .clients is enough I think.
> 
> 	static int dpcm_be_connect(...)
> 	{
> 		...
> -		list_add(&dpcm->list_be, &fe->dpcm[stream].be_clients);
> -		list_add(&dpcm->list_fe, &be->dpcm[stream].fe_clients);
> +		list_add(&dpcm->list_be, &fe->dpcm[stream].clients);
> +		list_add(&dpcm->list_fe, &be->dpcm[stream].clients);
> 		...
> 	}
> 
> 
> Thank you for your help !!
> Best regards
> ---
> Kuninori Morimoto
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about DPCM FE vs BE

[Kuninori Morimoto]

Hi Pierre-Louis

Thank you for your feedback

> It is my understanding that the current code would not support a case
> where a FE is also a BE.
> 
> That said, do we want to preclude it? at some point we probably want
> to get rid of the FE/BE distinction and have 'domains' that can be
> chained. So it may not be a good thing to cast a restriction in
> stone. If at some point we need a list of upstream/downstream clients
> maybe we should keep this.

Yeah, "domains" is nice idea !!

But, before that, I think we need to cleanup soc-pcm.
I'm reading it, but it is too much complex, and too unreadable...
I want to cleanup it first. I believe it can help
the conversion (= FE/BE to domains).

Thank you for your help !!
Best regards
---
Kuninori Morimoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about DPCM FE vs BE

[Pierre-Louis Bossart]

>> It is my understanding that the current code would not support a case
>> where a FE is also a BE.
>>
>> That said, do we want to preclude it? at some point we probably want
>> to get rid of the FE/BE distinction and have 'domains' that can be
>> chained. So it may not be a good thing to cast a restriction in
>> stone. If at some point we need a list of upstream/downstream clients
>> maybe we should keep this.
> 
> Yeah, "domains" is nice idea !!
> 
> But, before that, I think we need to cleanup soc-pcm.
> I'm reading it, but it is too much complex, and too unreadable...
> I want to cleanup it first. I believe it can help
> the conversion (= FE/BE to domains).

The idea of domains/constraint propagation is not mine BTW, it was 
presented by Lars some 2-3 years ago. there may be a note somewhere in 
the audio miniconference minutes.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about DPCM FE vs BE

[Kuninori Morimoto]

Hi Pierre-Louis

> >> That said, do we want to preclude it? at some point we probably want
> >> to get rid of the FE/BE distinction and have 'domains' that can be
> >> chained. So it may not be a good thing to cast a restriction in
> >> stone. If at some point we need a list of upstream/downstream clients
> >> maybe we should keep this.
> > 
> > Yeah, "domains" is nice idea !!
> > 
> > But, before that, I think we need to cleanup soc-pcm.
> > I'm reading it, but it is too much complex, and too unreadable...
> > I want to cleanup it first. I believe it can help
> > the conversion (= FE/BE to domains).
> 
> The idea of domains/constraint propagation is not mine BTW, it was
> presented by Lars some 2-3 years ago. there may be a note somewhere in
> the audio miniconference minutes.

Yes, I guess it was ELC-E.
My work (*) is to helpping him/his idea.

(*)	No categorize CPU/Codec/Platfrom
	modern style dai_link
	soc-core / soc-pcm cleanup (on going)
	(Semi) multi CPU support (will post)
	(Semi) no categorize CPU/Codec DAI (will post)

Thank you for your help !!
Best regards
---
Kuninori Morimoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] Question about DPCM FE vs BE

[Mark Brown]

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

On Thu, Oct 10, 2019 at 11:38:34AM +0900, Kuninori Morimoto wrote:

> > The idea of domains/constraint propagation is not mine BTW, it was
> > presented by Lars some 2-3 years ago. there may be a note somewhere in
> > the audio miniconference minutes.

> Yes, I guess it was ELC-E.
> My work (*) is to helpping him/his idea.

> (*)	No categorize CPU/Codec/Platfrom
> 	modern style dai_link
> 	soc-core / soc-pcm cleanup (on going)
> 	(Semi) multi CPU support (will post)
> 	(Semi) no categorize CPU/Codec DAI (will post)

I just dug the talk Lars did up the other day funnily enough:

        https://elinux.org/images/e/e7/Audio_on_Linux.pdf
        https://www.youtube.com/watch?v=6oQF2TzCYtQ

I'd posted something similar as well, the main issue is someone
getting the time to actually work on it :/

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel