[Alsa-devel] [RFC] alsa integer control ranges

[Takashi Iwai]

At Wed, 17 May 2006 08:03:43 +1000,
Benjamin Herrenschmidt wrote:
> 
> On Tue, 2006-05-16 at 14:27 +0200, Takashi Iwai wrote:
> > At Tue, 16 May 2006 14:02:20 +0200,
> > Johannes Berg wrote:
> > > 
> > > Apparently all alsa userspace programs including alsamixer suck. Hence,
> > > this patch is required to make them work properly. Why is it so hard to
> > > do these additions/subtractions in the program or maybe even in the alsa
> > > library? The alsa libraries already think they know better and mess up
> > > all kinds of things.
> > 
> > It's a pretty stupid question to ask why you are stupid :)
> > 
> > I don't think it's alsa-lib that prevents the negative or non-zero
> > integer range.  The fact amixer works implies that it's an
> > app-specific bug.  But I'm not 100% sure and need more
> > inside-looking.
> 
> Well, the problem I think is that pretty much all apps but amixer (and
> alsamixer whch works too for me at least) are bogus. It would have been
> good if Alsa had a more explicit specification that those values are not
> to be interpreted in the old OSS range :) In fact, best would have been
> to have the control structure carry a "unit" which a set of known units,
> one being dB, since the natural way of specifying an attenuation on any
> serious audio HW is dB and is negative... 

Yes, the dB expression has been discussed sometimes and we all agreed
that we definitely need it.  But stuck at the implemenation detail.

We have several issuess regarding the conversion of dB <-> raw volume
values:

- some codecs use linear volume
- some codecs have non-linear dB slopes
- unknown dB information for some controllers and codecs

And, USB and HD-audio devices/codecs provide the dB information.  Thus
the dB conversion table has to be evaluated dynamically for them.

So, it's not so easy as expected to create an API covering all
above...


Takashi