[alsa-devel] Master vs. Front/Rear/LFE/... elements

[Mark Brown]

On Thu, May 07, 2009 at 12:30:07PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > Indeed - for example, something that allowed audio routing to be
> > expressed in the mixing API would be a very big win for embedded systems
> > too.

> Right.  But this would also require some changes in the driver side,
> and it could be complicated.

It'd need to be optional, I think - similar to the approach ASoC is
using for the power routing (which is essentially the same information,
though it's not as joined up with the mixer controls yet as it should
be).

> Actually, we had this kind of information in the time of ALSA 0.5.
> However, it ended up with too burden to the driver code because one
> had to write a comprehensive static graph in the driver code itself
> (generated by hand!).  Also, some mixer elements are tightly coupled

IME maintaining the data isn't that much of an issue, it's a bit fiddly
but not intractible.  Of course, I'm always working from comprehensive
datasheets which isn't the case for everyone.  If the routing
information is optional people can always skip doing it if it's too
hard.

> with certain audio components, but some are pretty abstract and hard
> to put into a graph.  So, we reduced that in the newer API and
> implemented a straight array of control elements instead.

Oh, you'll always need chip wide controls outside a graph.  Not all
controls have anything to do with any particular bit of the audio stream
- bias control is an obvious example.

> Nevertheless, a sort of linking would be useful in addition to the
> current form.  For example, coupling between the control element and
> the PCM stream is missing, too.

That comes down to the same problem, really.

> Alternatively, we may have an external data outside the kernel
> driver.  In that case, the data can be expressed more flexibly
> (XML? Oh yeah :)

I'm not really enthusiastic about that prospect - getting the external
data onto the system and making sure it's in sync with the driver seems
like an error prone process.