About Cleanup ASoC

[Kuninori Morimoto]

Hi Cezary

Thank you for your feedback

> > 	+-- DeviceA --+
> > 	|+-----------+|
> > 	||Component  ||
> > 	||         [DAI]
> > 	||         [DAI]
> > 	...
> > 	||         [DAI]
> > 	||         [DAI]
> > 	|+-----------+|
> > 	+-------------+
(snip)
> 	+-- basic board --------+
> 	|+--------+             |
> 	|| CPU ch0| <--> CodecA |
> 	||     ch1| <-+         |
> 	|+--------+   |         |
> 	+-------------|---------+
> 
> 	+-- expansion board ----+
> 	|             |         |
> 	|             +-> CodecB|
> 	+-----------------------+
> 
> with suggestion to solve it with 1xComponent:NxCard relation which is 
> not supported by ASoC. However, we believe ASoC already presents 
> solutions to such problem, either through 1) compound card or less 
> commonly, by 2) splitting one big CPU-Card pair into several smaller pairs.
(snip)
> Perhaps there is something I'm missing but considering that ASoC does 
> have solutions to the raised problem, I do not see why either 1) or 2) 
> cannot be made use of to deal with the problem. I and Amadeo can 
> definitely help with 2) should you select it :)

Yes.

If my topic was "how to use expansion sound board",
case 1) and/or case 2) can solve the issue.
And Renesas is already using case 1) for a longer time.

But my topic is "it looks strange" in rough saying.

"Basic board sound" and "Expansion board sound" are
different sound card, in *intuitive*.
Case 1) handles it as "big one card". It works, but not intuitive.
For example, developer can understand it because he know the background,
but user will confuse, because they don't know the background.

My indicated image was very simple, but in reality,
it can be like this

	+-- basic board -------------------+
	|+-------------------+             |
	|| CPU <DAI0> --- ch0| <--> CodecA |
	||     <DAI1> --- ch1| <--> CodecB |
	||     <DAI2> --- ch2| <--+        |
 	||     <DAI3> --- ch3| <-+|        |
 	|+-------------------+   ||        |
	+------------------------||--------+

	+------ expansion board -||--------+
	|                        ||        |
	|                        |+> CodecC| (*)
	|                        +-> CodecD|
	+----------------------------------+

In intuitive, CodecC (*) is "first Codec of 2nd Sound Card",
but it is "3rd Codec of 1st Sound Card" in case 1) solution.
And thus, user need to know how many DAIs exist on basic board.

In addition, in my system case, it can use "MIXer" everywhere
which uses many DAIs (special DT is needed in this case).
<DAI0> and <DAI1> is using it in below sample.
In this case, interface number of CodecC (*) will be more
confusable for user who is thinking that it is
"first Codec of 2nd Sound Card".

	+-- basic board -------------------+
	|+-------------------+             |
	|| CPU <DAI0> --- ch0| <--> CodecA |
	||     <DAI1> -/     |             |
	||     <DAI2> --- ch1| <--> CodecB |
	||     <DAI3> --- ch2| <--+        |
 	||     <DAI4> --- ch3| <-+|        |
 	|+-------------------+   ||        |
	+------------------------||--------+

	+------ expansion board -||--------+
	|                        ||        |
	|                        |+> CodecC| (*)
	|                        +-> CodecD|
	+----------------------------------+


And case 2) need to have many Components.
Indeed this case can have "2 cards" in my system.
If we focus to "working system", I think this is good choice.

But, it is not good match to "Component" concept, in my opinion.
I can agree if some DAIs can be semantically grouped.
Your system is this case, if my understanding was correct.
But in my case, all DAIs/channel are same.
Having many "1xComponent:1xDAI" is strange, and not good match
the "Component concept", IMO.

Both case 1) and case 2) can handle my
"basic board sound" + "expansion board sound" system anyway.
But both are "stopgap solution", not "generic solution" for me for now.

I wanted to tell was we can expand ASoC with keeping "Component concept"
and keeping "intuitive usage", if we can have "1xComponent:NxCard" style.

I hope this mail tells my concern correctly.

Thank you for your help !!

Best regards
---
Kuninori Morimoto