Major problem with the current alsa mixer.

Major problem with the current alsa mixer.

[James Courtier-Dutton]

There is a MAJOR problem with the current alsa mixer.
How do I set a mixer volume to the 0 db point. I.E. no attenuation, and 
no gain.
Currently, we might have a value from 0 to 100%. Percent of what?
What this value means varies depending on the sound card hardware being 
used.
I think that this should all be changed to signed values, with a max and 
a min setting. With a value of 0 being equivalent to no-gain, 
no-attenuation. Each alsa-driver would then convert this signed value 
into a value actually written to the hardware register via a lookup table.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Jaroslav Kysela]

On Fri, 12 Sep 2003, James Courtier-Dutton wrote:

> There is a MAJOR problem with the current alsa mixer.
> How do I set a mixer volume to the 0 db point. I.E. no attenuation, and
> no gain.
> Currently, we might have a value from 0 to 100%. Percent of what?

Percent of the volume range.

> What this value means varies depending on the sound card hardware being
> used.
> I think that this should all be changed to signed values, with a max and
> a min setting. With a value of 0 being equivalent to no-gain,
> no-attenuation. Each alsa-driver would then convert this signed value
> into a value actually written to the hardware register via a lookup table.

Things are not as easy as you like. Using the signed notation for the
volume representation does not sound bad, but on the other side, it's
great to have zero as minimum value as well.

I have plans to extend the mixer interface to pass (and handle) the dB
resolution. But it will be done completely in the user space. The alsa-lib
will analyze information from the driver (hardware components) and then it
will use a predefined expressions for these transformations. I think that
we should not polute the kernel space with these "additional" things.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Takashi Iwai]

At Fri, 12 Sep 2003 09:23:13 +0200 (CEST),
Jaroslav wrote:
> 
> On Fri, 12 Sep 2003, James Courtier-Dutton wrote:
> 
> > There is a MAJOR problem with the current alsa mixer.
> > How do I set a mixer volume to the 0 db point. I.E. no attenuation, and
> > no gain.
> > Currently, we might have a value from 0 to 100%. Percent of what?
> 
> Percent of the volume range.
> 
> > What this value means varies depending on the sound card hardware being
> > used.
> > I think that this should all be changed to signed values, with a max and
> > a min setting. With a value of 0 being equivalent to no-gain,
> > no-attenuation. Each alsa-driver would then convert this signed value
> > into a value actually written to the hardware register via a lookup table.
> 
> Things are not as easy as you like. Using the signed notation for the
> volume representation does not sound bad, but on the other side, it's
> great to have zero as minimum value as well.
> 
> I have plans to extend the mixer interface to pass (and handle) the dB
> resolution. But it will be done completely in the user space. The alsa-lib
> will analyze information from the driver (hardware components) and then it
> will use a predefined expressions for these transformations. I think that
> we should not polute the kernel space with these "additional" things.

agreed.  it's a user-space thing.

but some additional information like min/max dB would be needed, too?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Jaroslav Kysela]

On Fri, 12 Sep 2003, Takashi Iwai wrote:

> > I have plans to extend the mixer interface to pass (and handle) the dB
> > resolution. But it will be done completely in the user space. The alsa-lib
> > will analyze information from the driver (hardware components) and then it
> > will use a predefined expressions for these transformations. I think that
> > we should not polute the kernel space with these "additional" things.
>
> agreed.  it's a user-space thing.
>
> but some additional information like min/max dB would be needed, too?

I think that we can have this database (including expressions which
converts hardware range to the dB range) in alsa-lib, too. It was one of
reasons why I am working on the lisp integration to alsa-lib, because we
can easy describe mathematic expressions with this language.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Takashi Iwai]

At Fri, 12 Sep 2003 12:31:32 +0200 (CEST),
Jaroslav wrote:
> 
> On Fri, 12 Sep 2003, Takashi Iwai wrote:
> 
> > > I have plans to extend the mixer interface to pass (and handle) the dB
> > > resolution. But it will be done completely in the user space. The alsa-lib
> > > will analyze information from the driver (hardware components) and then it
> > > will use a predefined expressions for these transformations. I think that
> > > we should not polute the kernel space with these "additional" things.
> >
> > agreed.  it's a user-space thing.
> >
> > but some additional information like min/max dB would be needed, too?
> 
> I think that we can have this database (including expressions which
> converts hardware range to the dB range) in alsa-lib, too. It was one of
> reasons why I am working on the lisp integration to alsa-lib, because we
> can easy describe mathematic expressions with this language.

oh, yes, it's good.  it would be easier to add new information, too.

well, we'll still need to provide a good method to tell the used codec
(or any other info) for user apps.  the same driver can have different
codecs, which behave quite differently.  as you know, even ac97 codecs
may have different dB range for the same element...


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Jaroslav Kysela]

On Fri, 12 Sep 2003, Takashi Iwai wrote:

> At Fri, 12 Sep 2003 12:31:32 +0200 (CEST),
> Jaroslav wrote:
> >
> > On Fri, 12 Sep 2003, Takashi Iwai wrote:
> >
> > > > I have plans to extend the mixer interface to pass (and handle) the dB
> > > > resolution. But it will be done completely in the user space. The alsa-lib
> > > > will analyze information from the driver (hardware components) and then it
> > > > will use a predefined expressions for these transformations. I think that
> > > > we should not polute the kernel space with these "additional" things.
> > >
> > > agreed.  it's a user-space thing.
> > >
> > > but some additional information like min/max dB would be needed, too?
> >
> > I think that we can have this database (including expressions which
> > converts hardware range to the dB range) in alsa-lib, too. It was one of
> > reasons why I am working on the lisp integration to alsa-lib, because we
> > can easy describe mathematic expressions with this language.
>
> oh, yes, it's good.  it would be easier to add new information, too.
>
> well, we'll still need to provide a good method to tell the used codec
> (or any other info) for user apps.  the same driver can have different
> codecs, which behave quite differently.  as you know, even ac97 codecs
> may have different dB range for the same element...

Yes, the best way to determine the ac97 codec confiration is reading of
ac97 registers. The proc interface might help us and we can move this
functionality to sysfs later.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Fri, 12 Sep 2003, James Courtier-Dutton wrote:
> 
> 
>>There is a MAJOR problem with the current alsa mixer.
>>How do I set a mixer volume to the 0 db point. I.E. no attenuation, and
>>no gain.
>>Currently, we might have a value from 0 to 100%. Percent of what?
> 
> 
> Percent of the volume range.
> 
> 
>>What this value means varies depending on the sound card hardware being
>>used.
>>I think that this should all be changed to signed values, with a max and
>>a min setting. With a value of 0 being equivalent to no-gain,
>>no-attenuation. Each alsa-driver would then convert this signed value
>>into a value actually written to the hardware register via a lookup table.
> 
> 
> Things are not as easy as you like. Using the signed notation for the
> volume representation does not sound bad, but on the other side, it's
> great to have zero as minimum value as well.

Zero as a minimum value is not very meaningfull in audio terms. With a 
mixer, the zero dB point is probably more use. The minimum value of a 
slider should be the equivalent of mute, so I think that instead of a 
minimum value, it should display "mute" for the user.
The user should be able to reduce the volume, and if they hit the 
minimum, mute automatically becomes active, but if they increase the 
volume again, mute automatically is disabled. I am thinking about the 
way a TV volume/mute control works. If one is muted, turning volume up 
or down automatically un-mutes the sound. This programming could 
probably be done at the application level, but I think that as so many 
people would want it that way, it should maybe move to alsa-lib.

> 
> I have plans to extend the mixer interface to pass (and handle) the dB
> resolution. But it will be done completely in the user space. The alsa-lib
> will analyze information from the driver (hardware components) and then it
> will use a predefined expressions for these transformations. I think that
> we should not polute the kernel space with these "additional" things.

I don't really mind where the code appears, all I care about is what the 
user sees. I just thought that as the hardware module knows best what to 
do with itself, it would be best to handle the volume calculation, but 
it could just as easily pass some equation/table up to alsa-lib to do 
the calculation instead.

One of the reasons for this request is if one has an application that 
defaults the mixer value to 100% because that sounds best for one bit of 
hardware, but finds the a 50% value is better for some other piece of 
hardware, with 100% causing massive distortion for the user due to too 
much gain/clipping. It would be nice for the application to be able to 
set 0 dB and know that it will sound the same for all sound card hardware.


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

If your "plans to extend the mixer interface" include my requests, then 
I will be happy to wait for their implementation.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Takashi Iwai]

At Fri, 12 Sep 2003 13:46:39 +0100,
James Courtier-Dutton wrote:
> 
> Jaroslav Kysela wrote:
> > On Fri, 12 Sep 2003, James Courtier-Dutton wrote:
> > 
> > 
> >>There is a MAJOR problem with the current alsa mixer.
> >>How do I set a mixer volume to the 0 db point. I.E. no attenuation, and
> >>no gain.
> >>Currently, we might have a value from 0 to 100%. Percent of what?
> > 
> > 
> > Percent of the volume range.
> > 
> > 
> >>What this value means varies depending on the sound card hardware being
> >>used.
> >>I think that this should all be changed to signed values, with a max and
> >>a min setting. With a value of 0 being equivalent to no-gain,
> >>no-attenuation. Each alsa-driver would then convert this signed value
> >>into a value actually written to the hardware register via a lookup table.
> > 
> > 
> > Things are not as easy as you like. Using the signed notation for the
> > volume representation does not sound bad, but on the other side, it's
> > great to have zero as minimum value as well.
> 
> Zero as a minimum value is not very meaningfull in audio terms. With a 
> mixer, the zero dB point is probably more use. The minimum value of a 
> slider should be the equivalent of mute, so I think that instead of a 
> minimum value, it should display "mute" for the user.

it's not always true.  some codes provide the minimum value which
doesn't mean mute.  in this case, another lower value would be needed
as the meaming of really minimum "mute".

> The user should be able to reduce the volume, and if they hit the 
> minimum, mute automatically becomes active, but if they increase the 
> volume again, mute automatically is disabled. I am thinking about the 
> way a TV volume/mute control works. If one is muted, turning volume up 
> or down automatically un-mutes the sound. This programming could 
> probably be done at the application level, but I think that as so many 
> people would want it that way, it should maybe move to alsa-lib.

hmm, it's a question whether it should go into alsa-lib.
another upper library seems better for me.

note that i don't mean against this idea at all - i'm absolutely for
this :)
the real problem is, of course, how to implement it for _all_
soundcards and architectures...
 

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Fri, 12 Sep 2003 13:46:39 +0100,
> James Courtier-Dutton wrote:
>>
>>Zero as a minimum value is not very meaningfull in audio terms. With a 
>>mixer, the zero dB point is probably more use. The minimum value of a 
>>slider should be the equivalent of mute, so I think that instead of a 
>>minimum value, it should display "mute" for the user.
> 
> 
> it's not always true.  some codes provide the minimum value which
> doesn't mean mute.  in this case, another lower value would be needed
> as the meaming of really minimum "mute".
> 
> 
>>The user should be able to reduce the volume, and if they hit the 
>>minimum, mute automatically becomes active, but if they increase the 
>>volume again, mute automatically is disabled. I am thinking about the 
>>way a TV volume/mute control works. If one is muted, turning volume up 
>>or down automatically un-mutes the sound. This programming could 
>>probably be done at the application level, but I think that as so many 
>>people would want it that way, it should maybe move to alsa-lib.
> 
> 
> hmm, it's a question whether it should go into alsa-lib.
> another upper library seems better for me.
> 
> note that i don't mean against this idea at all - i'm absolutely for
> this :)
> the real problem is, of course, how to implement it for _all_
> soundcards and architectures...
>  
> 
> Takashi
> 
> 
So, if we can agree on how the mixers will behave consistently in the 
application. I prefer the dB range myself, with 0 dB or -3.4 dB meaning 
the same thing for all sound cards, and minimul volume causing a "mute" 
to happen. (I think most TV and HiFi's work that way)
If a user has two different sound cards, the same mixer value on both 
cards should give the exact same volume out of the speakers.

We then modify alsa-lib and alsa-kernel to apply this behaviour to all 
sound cards.
I only initially thought that alsa-kernel was the best place, because 
the snd-emu10k1 happens to have a volume lookup table already, so I 
thought that it would be easy to apply that to all sound cards. It seems 
sensible to me, to do all hardware specific activity in a kernel module, 
and anything that it not strictly hardware specific in alsa-lib if 
possible. The kernel module will know if the minimum volume value in the 
volume register is mute or not, and can decide to activate a separate 
mute register if needed. I don't think alsa-lib can really provide this 
hardware specific functionallity.

Are there any sound cards where this "consistency in the application" is 
not possible?

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[Takashi Iwai]

At Fri, 12 Sep 2003 16:44:38 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 12 Sep 2003 13:46:39 +0100,
> > James Courtier-Dutton wrote:
> >>
> >>Zero as a minimum value is not very meaningfull in audio terms. With a 
> >>mixer, the zero dB point is probably more use. The minimum value of a 
> >>slider should be the equivalent of mute, so I think that instead of a 
> >>minimum value, it should display "mute" for the user.
> > 
> > 
> > it's not always true.  some codes provide the minimum value which
> > doesn't mean mute.  in this case, another lower value would be needed
> > as the meaming of really minimum "mute".
> > 
> > 
> >>The user should be able to reduce the volume, and if they hit the 
> >>minimum, mute automatically becomes active, but if they increase the 
> >>volume again, mute automatically is disabled. I am thinking about the 
> >>way a TV volume/mute control works. If one is muted, turning volume up 
> >>or down automatically un-mutes the sound. This programming could 
> >>probably be done at the application level, but I think that as so many 
> >>people would want it that way, it should maybe move to alsa-lib.
> > 
> > 
> > hmm, it's a question whether it should go into alsa-lib.
> > another upper library seems better for me.
> > 
> > note that i don't mean against this idea at all - i'm absolutely for
> > this :)
> > the real problem is, of course, how to implement it for _all_
> > soundcards and architectures...
> >  
> > 
> > Takashi
> > 
> > 
> So, if we can agree on how the mixers will behave consistently in the 
> application. I prefer the dB range myself, with 0 dB or -3.4 dB meaning 
> the same thing for all sound cards, and minimul volume causing a "mute" 
> to happen. (I think most TV and HiFi's work that way)

i think the mute behavior still needs to be discussed.
but i agree the dB expression is more obvious.

btw, the dB range is quite dependent on the card.
as i wrote, even the same value ranges on ac97 chips can mean
different dB range.  e.g. some ac97 chips have dB gain while usually
it should be 0dB.
that is the very reason that we should support dB expression.

> If a user has two different sound cards, the same mixer value on both 
> cards should give the exact same volume out of the speakers.

the resultant dB expression should be same, yes.
(the exact same volume is difficult to achieve in reality, though...)

> We then modify alsa-lib and alsa-kernel to apply this behaviour to all 
> sound cards.
> I only initially thought that alsa-kernel was the best place, because 
> the snd-emu10k1 happens to have a volume lookup table already, so I 
> thought that it would be easy to apply that to all sound cards. It seems 
> sensible to me, to do all hardware specific activity in a kernel module, 
> and anything that it not strictly hardware specific in alsa-lib if 
> possible.

well, the behavior above is "one" kind of abstraction.
and this doesn't mean that ALL applications want this.
therefore, we shouldn't put this into the drivers but solve on
the user-space as much as possible.

> The kernel module will know if the minimum volume value in the 
> volume register is mute or not, and can decide to activate a separate 
> mute register if needed. I don't think alsa-lib can really provide this 
> hardware specific functionallity.

a kernel driver will provide the necessary information for the
abstraction, but it won't do much jobs for such abstration.
i don't like to do the things such as the conversion between the dB
and raw values on the kernel space.  the user-space can do it better.

on ALSA 0.5.x, we had such dB information, but by some reason it was
dropped (i don't remember why).   now it's good time to revive this
old good guy :)

> Are there any sound cards where this "consistency in the application" is 
> not possible?

such as boost switch?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Major problem with the current alsa mixer.

[tom burkart]

On Sep 12, Takashi Iwai wrote:

> > >>Zero as a minimum value is not very meaningfull in audio terms. With a
> > >>mixer, the zero dB point is probably more use. The minimum value of a
> > >>slider should be the equivalent of mute, so I think that instead of a
> > >>minimum value, it should display "mute" for the user.
I don't believe this is a good idea.  In "live audio" you tend to have
mute groups and other advanced features that must be activated by a button
press rather than when the slider reaches the minus infinity (dB) point.

> > >>The user should be able to reduce the volume, and if they hit the
> > >>minimum, mute automatically becomes active, but if they increase the
Same comment as above.

> > >>volume again, mute automatically is disabled. I am thinking about the
> > >>way a TV volume/mute control works. If one is muted, turning volume up
> > >>or down automatically un-mutes the sound. This programming could
> > >>probably be done at the application level, but I think that as so many
> > >>people would want it that way, it should maybe move to alsa-lib.
Do you really want this to be a fancy "HiFi" system or potentially a
professional console?  I have no problem of two different APIs being
implemented in some library but I really wish not to be "forced" into
either.


> > So, if we can agree on how the mixers will behave consistently in the
> > application. I prefer the dB range myself, with 0 dB or -3.4 dB meaning
Agree.

> > the same thing for all sound cards, and minimul volume causing a "mute"
> > to happen. (I think most TV and HiFi's work that way)
That may well be so but disagree.

> > If a user has two different sound cards, the same mixer value on both
> > cards should give the exact same volume out of the speakers.
That should be the goal, implementation may differ somewhat.
On the other hand a flat 1-2 dB difference most people cannot even tell.


> therefore, we shouldn't put this into the drivers but solve on
> the user-space as much as possible.
Definitely agree.

tom.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf