[alsa-devel] [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card

[Peter Ujfalusi]

On Friday 17 December 2010 19:39:40 ext Jarkko Nikula wrote:
> This is targeted mostly to cross-device setups where single audio map
> defining routes around and between the codecs looks cleaner than defining
> and registering maps to each codec separately from machine init callbacks.
> 
> This could be also used to reduce simple machine init callbacks where only
> snd_soc_dapm_add_routes and snd_soc_dapm_sync are called. However, this
> does work only if the widgets names are unique in the system.
> 
> Idea of common audio map came from Peter Ujfalusi
> <peter.ujfalusi at nokia.com>.
> 
> Signed-off-by: Jarkko Nikula <jhnikula at gmail.com>
> Cc: Peter Ujfalusi <peter.ujfalusi at nokia.com>
> ---

For sure we need to have the card level DAPM map, when we have more than one 
codec in the system.
What I was thinking is more like to move the DAPM map from codec domain up to 
card level.
What I mean is, that when you build up your ASoC card, the DAPM map/routes are 
going to be attached to the card, and not to the codec.
If you have one codec on one card, then it is not going to change much, but, if 
you have multiple codecs you will still have one single DAPM map for the card, 
which stretches through multiple codecs.

When you have more codecs, you specify the prefix for the codecs, so the card 
DAPM map/route will have prefixed widgets. You use the prefixed widget names to 
make the connections needed in your system.

When you debug such a system you are anyway interested in the global DAPM status 
at every given time.

One thing that might need to be changed in DAPM is how we handle the 
connected/not connected endpoints.
Currently if you have DAPM_OUTPUT, and you do not connect it to speaker/HP/line, 
it is handled like it has some connection.
In multi comp this might be not what we want.
Also the treatment of the inputs might need to be changed.

In this example:
codec1:
DAPM_OUTPUT("to speaker")
DAPM_OUTPUT("to line out")

codec2:
DAPM_INPUT("line in")
DAPM_SWITCH("bypass")
DAPM_OUTPUT("to speaker")

{"bypass", "Switch", "Line in"},
{"to speaker", "Switch", "bypass"},


In machine you would have something like this:

DAPM_SPK("Speaker1")
DAPM_SPK("Speaker2")

{"Speaker1", NULL, "codec1 to speaker"},

{"Speaker2", NULL, "codec2 to speaker"},
{"codec2 Line in", NULL, "codec1 to line out"},

Now if you enable the bypass on codec2, it shall not bring up the codec2 bias, 
since we do not have full route.
If one starts the playback on codec1, and the codec2 bypass is enabled, than we 
need to power the codec1, and codec2 DAPM path.
If we do not have the:
{"codec2 Line in", NULL, "codec1 to line out"},
in the machine driver, we shall not power the bypass path in codec2, even if the 
switch is on, since the machine does not specified any connection.
IMHO this is more logical, than treating non connected OUTPUTs/INPUTs as 
connected.
But this is a different issue.

I think we shall try to move the DAPM mapping/routing from codec to card domain, 
and also change the behavior of not connected pins.

-- 
Péter