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

[Benjamin Herrenschmidt]

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

> > What are your opinions on this? Should this be required? And if so, why
> > do we even have the value.integer.min when we can't use it anyway? 
> 
> Right now, the range 0-max would make your life easier, I guess.
> 
> The min value is an API definition, and implemented and worked once.
> But no drivers used yet.  So, there might be a breakage.  It's of
> course to be fixed.

There is a lack of serious/professional audio drivers in the linux world
unfortunately... 

Ben.