[alsa-devel] <alsa-dev> RFC for OMAP4 audio driver

[Mark Brown]

On Wed, Sep 02, 2009 at 08:55:16PM -0500, Lopez Cruz, Misael wrote:

> I'm not familiar with the concept of an audio hub, but is it
> something like a codec that can have 'slave' codecs connected to
> it (like in cascade fashion)?

Not quite.  The idea is that in a system like a phone where you have
multiple sources and sinks for audio (the CPU, bluetooth, GSM, onboard
mics and speaker...) an audio hub provides a central place to route and
mix all the audio signals.  This can be purely analogue, purely digital
or a mix of both - generally for the full thing you need a mix of both.
The OMAP4 ABE is an example of this in the digital domain.

The idea is that it becomes possible to do things like run the audio
subsystem while the rest of the system is powered down (eg, during a
call) and that the CPU doesn't need to spend time on basic audio tasks.

> Do we have any audio hub CODEC already in SoC to use as a
> reference?

The OpenMoko phones are probably the most obvious example of this in
mainline - they have GSM connected to the CODEC via a line input and
bluetooth via a second DAI.

> > This is the sort of issue I'm talking about above which is 
> > helped by explicitly representing all the DAIs in the system. 
> >  With the DAIs visible it should just become a case of 
> > hooking up the links between the devices in the usual ASoC fashion.

> If the ABE is considered as a separate CODEC, then it should have
> its own DAIs for the connection with the processor, even it the
> codec itself resides in the processor. What about the client CODECs?

I beleive this will make life easier with the current design.  Looking
at the system diagrams the CPU core is relating to the ABE as though it
were an external device, and the design that was proposed with a unified
ABE/TWL6030 driver is doing pretty much that.  All I'm really saying
here is that the links between the OMAP4 and the TWL6030 should be
explicitly represented so that if a board design hooks things up
differently for some reason then the drivers can cope.

> They will also have their DAIs which should be connected to the
> physical outputs of ABE (McPDM, McBSP, ...), and that confuses me.
> AFAIK, SoC allows to have multiple CODECs attached to the same
> processor, but not a CODEC connected to the output of another CODEC.

At the minute it's a bit tricky but it's definitely something that ought
to be supported - you may remember the refactoring that was done to
unify the CODEC and CPU DAI structures, this sort of use case was one of
the motivators for that.  Where there's problems the core isn't a fixed
thing, we can change it if required.