[RFC] alsa integer control ranges

[RFC] alsa integer control ranges

[Johannes Berg]

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.

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? 

The code this patch applies against is in
http://johannes.sipsolutions.net/snd-aoa.git/ but that isn't all too
relevant, the patch serves just as an illustration of what is wrong
here.

Thanks,
johannes

--- snd-aoa.orig/aoa/codecs/onyx/snd-aoa-codec-onyx.c	2006-05-16 12:13:39.663950213 +0200
+++ snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c	2006-05-16 12:14:13.698643898 +0200
@@ -102,8 +102,8 @@ static int onyx_snd_vol_info(struct snd_
 {
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
 	uinfo->count = 2;
-	uinfo->value.integer.min = -128;
-	uinfo->value.integer.max = -1;
+	uinfo->value.integer.min = -128+128;
+	uinfo->value.integer.max = -1+128;
 	return 0;
 }
 
@@ -115,8 +115,8 @@ static int onyx_snd_vol_get(struct snd_k
 
 	onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, &l);
 	onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, &r);
-	ucontrol->value.integer.value[0] = l;
-	ucontrol->value.integer.value[1] = r;
+	ucontrol->value.integer.value[0] = l+128;
+	ucontrol->value.integer.value[1] = r+128;
 	return 0;
 }
 
@@ -125,8 +125,8 @@ static int onyx_snd_vol_put(struct snd_k
 {
 	struct onyx *onyx = snd_kcontrol_chip(kcontrol);
 
-	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]);
-	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]);
+	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]-128);
+	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]-128);
 	/* FIXME: we could be checking if anything changed */
 	return 1;
 }
@@ -145,8 +145,8 @@ static int onyx_snd_inputgain_info(struc
 {
 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
 	uinfo->count = 1;
-	uinfo->value.integer.min = 3;
-	uinfo->value.integer.max = 28;
+	uinfo->value.integer.min = 3-3;
+	uinfo->value.integer.max = 28-3;
 	return 0;
 }
 
@@ -157,7 +157,7 @@ static int onyx_snd_inputgain_get(struct
 	u8 ig;
 
 	onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &ig);
-	ucontrol->value.integer.value[0] = ig & ONYX_ADC_PGA_GAIN_MASK;
+	ucontrol->value.integer.value[0] = (ig & ONYX_ADC_PGA_GAIN_MASK)-3;
 	return 0;
 }
 
@@ -169,7 +169,7 @@ static int onyx_snd_inputgain_put(struct
 
 	onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &val);
 	val &= ~ONYX_ADC_PGA_GAIN_MASK;
-	val |= ucontrol->value.integer.value[0] & ONYX_ADC_PGA_GAIN_MASK;
+	val |= (ucontrol->value.integer.value[0]+3) & ONYX_ADC_PGA_GAIN_MASK;
 	onyx_write_register(onyx, ONYX_REG_ADC_CONTROL, val);
 	return 1;
 }

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

[Takashi Iwai]

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.

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


Takashi

Re: [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.

Re: [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

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Wed, 2006-05-17 at 11:59 +0200, Takashi Iwai wrote:

> We have several issuess regarding the conversion of dB <-> raw volume
> values:
> 
> - some codecs use linear volume
> - some codecs have non-linear dB slopes

And I made a huge table so that the slope is linear! Otherwise it'd have
been logarithmic. Anything else is pretty user-unfriendly though.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

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

[Takashi Iwai]

At Wed, 17 May 2006 14:16:58 +0200,
Johannes Berg wrote:
> 
> On Wed, 2006-05-17 at 11:59 +0200, Takashi Iwai wrote:
> 
> > We have several issuess regarding the conversion of dB <-> raw volume
> > values:
> > 
> > - some codecs use linear volume
> > - some codecs have non-linear dB slopes
> 
> And I made a huge table so that the slope is linear! Otherwise it'd have
> been logarithmic. Anything else is pretty user-unfriendly though.

It's not the question of user-friendliness.  As the end result, the dB
expression would be the best for users.  No doubt.

The question is where to implement a huge table or a complex
conversion function -- whether in the driver or in alsa-lib.


Takashi

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Wed, 2006-05-17 at 14:35 +0200, Takashi Iwai wrote:

> The question is where to implement a huge table or a complex
> conversion function -- whether in the driver or in alsa-lib.

Well if it was in the alsa-lib I could just give it a formula that
contains an exponential and some constants, and that's all it needs. But
in the kernel it has to be a lookup table since I can't do floating
point math easily.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

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

[Benjamin Herrenschmidt]

On Wed, 2006-05-17 at 14:35 +0200, Takashi Iwai wrote:

> The question is where to implement a huge table or a complex
> conversion function -- whether in the driver or in alsa-lib.

The lib of course

Ben.

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On Tue, 2006-05-16 at 14:27 +0200, Takashi Iwai wrote:

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

Basically, I think what I'm saying is: "why doesn't alsa-lib shift the
range to start at zero?"
It already does so many manipulations, that one wouldn't hurt...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

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

[Takashi Iwai]

At Wed, 17 May 2006 14:17:54 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-05-16 at 14:27 +0200, Takashi Iwai wrote:
> 
> > 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. 
> 
> Basically, I think what I'm saying is: "why doesn't alsa-lib shift the
> range to start at zero?"
> It already does so many manipulations, that one wouldn't hurt...

True, but then it's a workaround only for your driver right now :)

The API clearly defines the non-zero minimum value, so manipulating it
in alsa-lib sounds self-inconsistent.


Takashi

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

[Jaroslav Kysela]

On Tue, 16 May 2006, 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 better to fix apps, if they are broken.

						Jaroslav

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

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

[Benjamin Herrenschmidt]

On Tue, 2006-05-16 at 14:31 +0200, Jaroslav Kysela wrote:
> On Tue, 16 May 2006, 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 better to fix apps, if they are broken.

Problem is, they are currently all broken (pretty much) and thus unless
we want to release a driver that won't work with any current distros,
we'll have to whack the ranges :(

Ben.

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

[Jaroslav Kysela]

On Wed, 17 May 2006, Benjamin Herrenschmidt wrote:

> On Tue, 2006-05-16 at 14:31 +0200, Jaroslav Kysela wrote:
> > On Tue, 16 May 2006, 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 better to fix apps, if they are broken.
> 
> Problem is, they are currently all broken (pretty much) and thus unless
> we want to release a driver that won't work with any current distros,
> we'll have to whack the ranges :(

It's better to have problematic values by default and define a module 
(driver) option to enable the "compatible" behaviour. Otherwise the apps 
will be never fixed. Also, ideally, you can fix apps and send patches to 
authors and/or create problematic controls in the dummy driver 
(drivers/dummy.c) and send a notice to app developers that they have 
broken apps and ask to fix them refering to the dummy driver test case.

						Jaroslav

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

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Wed, 2006-05-17 at 08:41 +0200, Jaroslav Kysela wrote:

> It's better to have problematic values by default and define a module 
> (driver) option to enable the "compatible" behaviour. 

I just committed the patch to be always compatible. I'm not going to
clutter the code even more.

> Otherwise the apps 
> will be never fixed. 

True.

> Also, ideally, you can fix apps and send patches to 
> authors and/or create problematic controls in the dummy driver 
> (drivers/dummy.c) and send a notice to app developers that they have 
> broken apps and ask to fix them refering to the dummy driver test case. 

The dummy driver isn't a bad idea, all the rest is. There are *dozens*
of broken apps, and most of their code is horrid. I couldn't even fix
alsamixer for the 3..28 range brokenness.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

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

[Takashi Iwai]

At Wed, 17 May 2006 08:04:18 +1000,
Benjamin Herrenschmidt wrote:
> 
> On Tue, 2006-05-16 at 14:31 +0200, Jaroslav Kysela wrote:
> > On Tue, 16 May 2006, 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 better to fix apps, if they are broken.
> 
> Problem is, they are currently all broken (pretty much) and thus unless
> we want to release a driver that won't work with any current distros,
> we'll have to whack the ranges :(

Well that's a big dilemma.  Surely you want a stable driver and don't
want to see the flood of bug reports.

The mixer stuff is the weakest point in the current ALSA
implementation, and it has to be sorted out better.
Almost all existing mixer GUI programs are more or less buggy or quite
user-unfriendly.


Takashi

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Wed, 2006-05-17 at 11:47 +0200, Takashi Iwai wrote:
> 
> The mixer stuff is the weakest point in the current ALSA
> implementation, and it has to be sorted out better. 

Here's another item for the wishlist:

Give applications an option to tell the library they can handle
ENUMERATED controls, and then don't mess with them. And then, if the
application *doesn't* tell the lib it can handle ENUMERATED controls,
split up *all* the enumerated controls instead of just the "Capture
Source" one. The current behaviour:
 - it splits up the Capture Source one but no others
 - it doesn't allow apps to get the real intention

is bogus for the following reasons:
 - most GUI programs get *checkboxes* that are mutually exclusive
 - a lot of GUI programs that cannot handle ENUMERATED items
   totally screw up when they still get an enumerated one just
   because it had a different name.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

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

[Lee Revell]

On Tue, 2006-05-16 at 14:02 +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.
> 
> 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? 
> 
> The code this patch applies against is in
> http://johannes.sipsolutions.net/snd-aoa.git/ but that isn't all too
> relevant, the patch serves just as an illustration of what is wrong
> here.
> 

Ummm... what problem is this patch fixing?

Lee

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Tue, 2006-05-16 at 10:53 -0400, Lee Revell wrote:

> Ummm... what problem is this patch fixing?

The problems that
(a) kmix, gnome-alsamixer, gnome-volume-control and others can't
    properly use the playback volume control because it has a range
    that doesn't start at 0
and
(b) alsamixer can't properly control the capture volume control for
    apparently the same reason

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

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

[Wolfgang Pfeiffer]

On Tue, May 16, 2006 at 04:55:15PM +0200, Johannes Berg wrote:
> On Tue, 2006-05-16 at 10:53 -0400, Lee Revell wrote:
> 
> > Ummm... what problem is this patch fixing?
> 
> The problems that
> (a) kmix, gnome-alsamixer, gnome-volume-control and others can't
>     properly use the playback volume control because it has a range
>     that doesn't start at 0

True if you only use kmix, that via 'ps ax' shows up as something like this:

[ ... ] kmix [kdeinit] -caption KMix -icon kmix -miniicon kmix

But if you - separately and additionally - add the "Sound Mixer"
applet to the KDE kicker (the panel) *plus* make sure you split the
volume control slider for the "Sound Mixer" channel you have a working
volume control .. :)
At least this is how it works here, with 
"Kmix Panel Applet 2.6 (Using KDE 3.5.2)", and on Debian unstable .. 

If I play with these apps there seem to be glitches, so they do not
seem to work "properly". But with a bit of fiddling between what KDE
calls "Sound Mixer" and "Kmix" (both actually seem to be part of the
same application, i.e. kmix) you should have a working volume slider
... 

HTH

Best Regards
Wolfgang

-- 
Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Re: [RFC] alsa integer control ranges

[Benjamin Herrenschmidt]

On Tue, 2006-05-16 at 14:02 +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.

alsamixer works for me with negative ranges... but all other apps don't
and there are various bugs, I blame apps converted from OSS....

> 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? 
> 
> The code this patch applies against is in
> http://johannes.sipsolutions.net/snd-aoa.git/ but that isn't all too
> relevant, the patch serves just as an illustration of what is wrong
> here.
> 
> Thanks,
> johannes
> 
> --- snd-aoa.orig/aoa/codecs/onyx/snd-aoa-codec-onyx.c	2006-05-16 12:13:39.663950213 +0200
> +++ snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c	2006-05-16 12:14:13.698643898 +0200
> @@ -102,8 +102,8 @@ static int onyx_snd_vol_info(struct snd_
>  {
>  	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
>  	uinfo->count = 2;
> -	uinfo->value.integer.min = -128;
> -	uinfo->value.integer.max = -1;
> +	uinfo->value.integer.min = -128+128;
> +	uinfo->value.integer.max = -1+128;
>  	return 0;
>  }
>  
> @@ -115,8 +115,8 @@ static int onyx_snd_vol_get(struct snd_k
>  
>  	onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, &l);
>  	onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, &r);
> -	ucontrol->value.integer.value[0] = l;
> -	ucontrol->value.integer.value[1] = r;
> +	ucontrol->value.integer.value[0] = l+128;
> +	ucontrol->value.integer.value[1] = r+128;
>  	return 0;
>  }
>  
> @@ -125,8 +125,8 @@ static int onyx_snd_vol_put(struct snd_k
>  {
>  	struct onyx *onyx = snd_kcontrol_chip(kcontrol);
>  
> -	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]);
> -	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]);
> +	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]-128);
> +	onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]-128);
>  	/* FIXME: we could be checking if anything changed */
>  	return 1;
>  }
> @@ -145,8 +145,8 @@ static int onyx_snd_inputgain_info(struc
>  {
>  	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
>  	uinfo->count = 1;
> -	uinfo->value.integer.min = 3;
> -	uinfo->value.integer.max = 28;
> +	uinfo->value.integer.min = 3-3;
> +	uinfo->value.integer.max = 28-3;
>  	return 0;
>  }
>  
> @@ -157,7 +157,7 @@ static int onyx_snd_inputgain_get(struct
>  	u8 ig;
>  
>  	onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &ig);
> -	ucontrol->value.integer.value[0] = ig & ONYX_ADC_PGA_GAIN_MASK;
> +	ucontrol->value.integer.value[0] = (ig & ONYX_ADC_PGA_GAIN_MASK)-3;
>  	return 0;
>  }
>  
> @@ -169,7 +169,7 @@ static int onyx_snd_inputgain_put(struct
>  
>  	onyx_read_register(onyx, ONYX_REG_ADC_CONTROL, &val);
>  	val &= ~ONYX_ADC_PGA_GAIN_MASK;
> -	val |= ucontrol->value.integer.value[0] & ONYX_ADC_PGA_GAIN_MASK;
> +	val |= (ucontrol->value.integer.value[0]+3) & ONYX_ADC_PGA_GAIN_MASK;
>  	onyx_write_register(onyx, ONYX_REG_ADC_CONTROL, val);
>  	return 1;
>  }
> 

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

[Lee Revell]

On Wed, 2006-05-17 at 08:00 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2006-05-16 at 14:02 +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.
> 
> alsamixer works for me with negative ranges... but all other apps don't
> and there are various bugs, I blame apps converted from OSS....

kmix is the worst by far, someone really needs to fix it.  It has so
many bugs that it's unusable for debugging ALSA, we have to tell people
to use alsamixer.

Lee