Re: [RFC] Extra info via the TLV interface

[James Courtier-Dutton <James@superbug.co.uk>]

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.

> 
>> 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.

> 
>> 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.

> 
> 
> 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.

> 
> 
> Takashi

James

-------------------------------------------------------------------------
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