Lennart Poettering wrote: > 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 > If you guys decide to go the user-space route, please consider including an optional text description of each control element, preferrably with localization support. Thanks, Pavel. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
