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.