[RFC] Extra info via the TLV interface

[RFC] Extra info via the TLV interface

[James Courtier-Dutton]

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.
2) Whether the control is digital or analog.
3) Some description of the routing of the control. i.e. how it links to
other controls.
4) Both "short" and "long" mixer control names.
5) Control grouping. I.e. to have mixer controls "Front" and "Surround"
next to each other.

I know (1) sort of works just by adding playback or capture to the
control name, but it seems to fail in some ambiguous cases. E.g.
"Capture feedback", "Mic Boost", "HD Source", "HD Channel"

Any comments?

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

Re: [RFC] Extra info via the TLV interface

[Jaroslav Kysela]

On Mon, 4 Sep 2006, 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.
> 2) Whether the control is digital or analog.
> 3) Some description of the routing of the control. i.e. how it links to
> other controls.
> 4) Both "short" and "long" mixer control names.
> 5) Control grouping. I.e. to have mixer controls "Front" and "Surround"
> next to each other.

In my opinion, all these GUI hints should be elsewhere (userspace), 
otherwise we'll end up with drivers containing digital photos of 
sound chips in the TLV structure :-)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

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

Re: [RFC] Extra info via the TLV interface

[Liam Girdwood]

On Mon, 2006-09-04 at 13: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.

Agreed, it would also be nice to know about sidetone/bypass.

> 2) Whether the control is digital or analog.
> 3) Some description of the routing of the control. i.e. how it links to
> other controls.

Fwiw, I've created a patch for ASoC that uses the audio routing map
(includes how controls are linked to other controls) within ASoC to
enable easy scenario setting. This allows a route to be be automatically
created (and powered) by specifing the source and sink e.g.

"Left DAC" --> "Left Headphone"

It wouldn't be difficult to add code here that could also specify the
active controls for that route. i.e. active route controls could be
highlighted to make using the mixer tools easier.

If anyone is interested, patch is here:-

http://www.rpsys.net/openzaurus/patches/alsa/asoc-scenario-v0.3.patch

Atm, it's ASoC only as it requires a map of the machine audio subsystem.

> 4) Both "short" and "long" mixer control names.
> 5) Control grouping. I.e. to have mixer controls "Front" and "Surround"
> next to each other.
> 
> I know (1) sort of works just by adding playback or capture to the
> control name, but it seems to fail in some ambiguous cases. E.g.
> "Capture feedback", "Mic Boost", "HD Source", "HD Channel"
> 
> Any comments?
> 

I'd also like to pass in log time values for ALC/AGC.

Liam



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

Re: [RFC] Extra info via the TLV interface

[Liam Girdwood]

On Mon, 2006-09-04 at 15:04 +0200, Jaroslav Kysela wrote:
> On Mon, 4 Sep 2006, 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.
> > 2) Whether the control is digital or analog.
> > 3) Some description of the routing of the control. i.e. how it links to
> > other controls.
> > 4) Both "short" and "long" mixer control names.
> > 5) Control grouping. I.e. to have mixer controls "Front" and "Surround"
> > next to each other.
> 
> In my opinion, all these GUI hints should be elsewhere (userspace), 
> otherwise we'll end up with drivers containing digital photos of 
> sound chips in the TLV structure :-)
> 

We've almost got a "digital photo" of each sound chip in ASoC atm. It's
good for a few things (including GUI hints) :-

 o Power Management. Knowing when to enable/disable individual chip and
machine audio components (based on any active streams and current mixer
settings).
 o Scenario setting. Allowing a route to be set from source to sink
within a machine. I'd like to eventually have some kind of scenario
description in the card conf file for each use case. 

Atm, the audio map is within the driver code, but it could eventually be
moved into userspace. The only question is whether the PM will work well
in userspace.

Liam


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

Re: [RFC] Extra info via the TLV interface

[Takashi Iwai]

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

Re: [RFC] Extra info via the TLV interface

[James Courtier-Dutton]

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

Re: [RFC] Extra info via the TLV interface

[Takashi Iwai]

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

Re: [RFC] Extra info via the TLV interface

[Jaroslav Kysela]

On Mon, 4 Sep 2006, Takashi Iwai wrote:

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

Note that alsactl or probably alsa-lib should be improved. We cannot 
expect that names won't change and name cleanups are preferred. I would 
propose to create a database with name change description to prevent these 
errors and allow users switching between two ALSA driver versions more 
nicely.

The question is, if applications use these names to do something special
(if they compares them with own strings). Of course, we will break the 
compatibility in this case. I would like to discuss, if adding a function
like

int snd_mixer_compat_control_name(const char *name,
				  const char *alsa_version,
			          char *new_name, int new_name_size)

would be sufficient to ALSA API.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

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

Re: [RFC] Extra info via the TLV interface

[Takashi Iwai]

At Tue, 5 Sep 2006 08:30:42 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Mon, 4 Sep 2006, Takashi Iwai wrote:
> 
> > 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.
> 
> Note that alsactl or probably alsa-lib should be improved. We cannot 
> expect that names won't change and name cleanups are preferred. I would 
> propose to create a database with name change description to prevent these 
> errors and allow users switching between two ALSA driver versions more 
> nicely.
> 
> The question is, if applications use these names to do something special
> (if they compares them with own strings). Of course, we will break the 
> compatibility in this case. I would like to discuss, if adding a function
> like
> 
> int snd_mixer_compat_control_name(const char *name,
> 				  const char *alsa_version,
> 			          char *new_name, int new_name_size)
> 
> would be sufficient to ALSA API.

Hmm...  How would this function be used?
I still don't get it.  Is it a function to be called by apps, or a
function used in alsa-lib internaly?


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

Re: [RFC] Extra info via the TLV interface

[Jaroslav Kysela]

On Tue, 5 Sep 2006, Takashi Iwai wrote:

> At Tue, 5 Sep 2006 08:30:42 +0200 (CEST),
> Jaroslav Kysela wrote:
> > 
> > On Mon, 4 Sep 2006, Takashi Iwai wrote:
> > 
> > > 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.
> > 
> > Note that alsactl or probably alsa-lib should be improved. We cannot 
> > expect that names won't change and name cleanups are preferred. I would 
> > propose to create a database with name change description to prevent these 
> > errors and allow users switching between two ALSA driver versions more 
> > nicely.
> > 
> > The question is, if applications use these names to do something special
> > (if they compares them with own strings). Of course, we will break the 
> > compatibility in this case. I would like to discuss, if adding a function
> > like
> > 
> > int snd_mixer_compat_control_name(const char *name,
> > 				  const char *alsa_version,
> > 			          char *new_name, int new_name_size)
> > 
> > would be sufficient to ALSA API.
> 
> Hmm...  How would this function be used?
> I still don't get it.  Is it a function to be called by apps, or a
> function used in alsa-lib internaly?

An application should decide (thus this API would be exported).. I would 
like to know if we have also other apps depending on the control name 
strings these days or if it's only the alsactl problem (which makes the 
situation easier).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

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

Re: [RFC] Extra info via the TLV interface

[Takashi Iwai]

At Tue, 5 Sep 2006 17:32:33 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Tue, 5 Sep 2006, Takashi Iwai wrote:
> 
> > At Tue, 5 Sep 2006 08:30:42 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > > 
> > > On Mon, 4 Sep 2006, Takashi Iwai wrote:
> > > 
> > > > 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.
> > > 
> > > Note that alsactl or probably alsa-lib should be improved. We cannot 
> > > expect that names won't change and name cleanups are preferred. I would 
> > > propose to create a database with name change description to prevent these 
> > > errors and allow users switching between two ALSA driver versions more 
> > > nicely.
> > > 
> > > The question is, if applications use these names to do something special
> > > (if they compares them with own strings). Of course, we will break the 
> > > compatibility in this case. I would like to discuss, if adding a function
> > > like
> > > 
> > > int snd_mixer_compat_control_name(const char *name,
> > > 				  const char *alsa_version,
> > > 			          char *new_name, int new_name_size)
> > > 
> > > would be sufficient to ALSA API.
> > 
> > Hmm...  How would this function be used?
> > I still don't get it.  Is it a function to be called by apps, or a
> > function used in alsa-lib internaly?
> 
> An application should decide (thus this API would be exported).. I would 
> like to know if we have also other apps depending on the control name 
> strings these days or if it's only the alsactl problem (which makes the 
> situation easier).

I'm very much skeptical that apps would take this function.

But, this is surely not the problem of only alsactl.  For example,
kmix would suffer from the renaming similarly since it saves/restores
the setting in own config file for each session like alsactl.


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