On Thu, 07.05.09 12:30, Takashi Iwai (tiwai@suse.de) wrote:
At Thu, 7 May 2009 11:09:16 +0100, Mark Brown wrote:
On Thu, May 07, 2009 at 10:49:22AM +0200, Takashi Iwai wrote:
IMO, the best would be a total rewrite of the current mixer API, as I mentioned some times. Right now it's more complicated than needed, but not powerful enough to handle exceptional cases.
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.
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 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.
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.
Alternatively, we may have an external data outside the kernel driver. In that case, the data can be expressed more flexibly (XML? Oh yeah :)
That would actually work for me and I wouldn't even be that disgusted by this usage of XML ;-)
_From the PA perspective I actually don't really need the full routing of the sound card exposed. I always want to focus on actual end-user use cases instead of exposing the full mixer capabilities. All I need to know is which elements are in the pipeline from my PCM streams to a specific output, resp. from a specific input to my PCM stream and a more high-level idea what those elements actually mean. i.e. all I need would be an API like this:
int snd_pcm_get_mixer_path(snd_pcm_t *pcm, snd_mixer_selem_id_t path[], unsigned n);
This would simply return an array of mixer element ids that are in the pipeline to the output, resp. from the input, ordered.
Then, a trivial API that allows me to identify what a mixer element's use is would be all I need.
Lennart