At Mon, 04 Sep 2006 13:48:48 +0100, James Courtier-Dutton wrote: > > Hi, > > I would like to now pass extra info regarding the controls via the TLV > interface. > 1) Whether the control is Playback, Capture or Both. This could be, in theory, achieved by re-defining every control strictly with a Playback/Capture modifier. But, the problem is that alsactl (and likely other programs) won't handle correctly the name mismatch as default. > 2) Whether the control is digital or analog. This could be embedded in a name string, too, although the external info might be a better choice. But, we'd be better to be careful about this classification. For example, is this only digital and analog? What about the cases with SPDIF and ADAT? etc etc... > 3) Some description of the routing of the control. i.e. how it links to > other controls. I suppose it's optional? Good for some devices, though. > 4) Both "short" and "long" mixer control names. I understand the demand but this would be better in the user-space, IMO. The long name is basically a mapped string from the short name, especially if you consider the internationalization... > 5) Control grouping. I.e. to have mixer controls "Front" and "Surround" > next to each other. I feel this is too much for the driver, too. How would you use this information, BTW? Even if we have grouping, it doesn't make any sense unless the apps use such information. That is, we should begin with the change of alsa-lib mixer abstraction before the driver side. Note that I'm not against implementation using TLV. (Of course, depending on the implementation. If the driver-side implementaion is much easier, why not?) I'm just against the too much standardization in the driver side. IMO, the abstraction of such meta information quite often results in a too complicated but rarely used data protocol. For example, USB audio device has a compehensive description for most of the things above. But, no-one wants to implement details nowadays (Creative tried once with Extigy but seems giving up) because it simply increases the complexity in the driver handling. So, first of all, let's think twice whether the proposed things are really needed inevitablly. At next, think about the implementation in the alsa-lib and apps, what we'd need for that. (I don't only mean user-space solutions but the necessary changes in user-space for additional kernel changes.) Then, at last, consider the modification of the driver side. That is, the proposal for the kernel change should be always coupled with the corresponding user-space changes. Looking around the driver code, you'll find many rotten stuff that had been implemented but actually never used, just because there are no apps/infrastructures to use such features. We should avoid it any more... Takashi ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
