[alsa-devel] Question about DPCM FE vs BE
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
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
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
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.
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
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 :/
participants (3)
-
Kuninori Morimoto -
Mark Brown -
Pierre-Louis Bossart