On Thu, 07.05.09 12:30, Takashi Iwai (tiwai@xxxxxxx) 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 -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
