>> Another point: the matrix mixer is now (with patch II from Paul) >> read/write. In write mode it takes 3 parameters: >> source,destination,gain. With the amixer patch I submitted some days ago >> it is possible to actually read it, passing source and destination >> channels as parameters to the cget option. In the driver, the return >> values use the same structure as the parameters. Should I respect the >> parameters index (returning the gain value in value[2]) or should I >> consider that return values start at value[0] ? > >Note that this behaviour is non-standard. You simply moved the addressing >outside the sndrv_ctl_elem_id structure which is quite bad in the sense of >common API. I think that it would be nice to invent some group controls >represented inside the kernel space only with one structure rather than >doing things which doesn't follow the API design.
it would be nice, but the last time we discussed this, no viable solutions emerged, which is why the code still works this way. ALSA is missing "standard" ways of doing a variety of things, and we can't not make this functionality available because its in a queue of other things that need "standardization". >For example, alsactl doesn't know about your addresing thus is impossible >to save and restore the settings of this card via this universal utility. but amixer+script can. in fact, amixer+script is actually more flexible than alsactl, and i have to admit that i find it a bit troubling that both these tools exist. is there something that amixer cannot do that alsactl can? ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
