At Mon, 04 Sep 2006 16:31:12 +0100, James Courtier-Dutton wrote: > > Takashi Iwai wrote: > > 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. > Where is the name mismatch. It is just extra information. Sorry, I meant to re-define every control "name" that is not conforming in the above. Renaming a mixer element _always_ results in a name mismatch _error_ in alsactl. It's handled as an error, not a warning. > >> 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... > > For "digital or analog", I mean this should tell the user whether the > control is before of after the ADC/DAC. I.e. Analog if it is on the > analog side, digital if it is on the digital side. For example, for > sound capture, it is better to get the pre-amp before the ADC set to the > correct gain level, and leave and post ADC (i.e. digital) controls at > 0dB. As you can see, from my explanation, we don't need SPDIF and ADAT > specific options. OK, then I misinterepreted from the words analog/digital. Still, I'd like to see the real use-cases by applications... > >> 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. > > I think this option is probably low priority, but certainly useful when > one has sound cards with many controls. Yes, I know such cases, too. But, as I mentioned, we should start from the idea how to improve the mixer apps (or alsa-lib API), then. The top-down method would be more efficient for defining a protocol. > > 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... > > Well, if it has never been used, we can just remove it. With cost of API/ABI incompatibility? Most likely not... 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
