[alsa-devel] amixer: convert percentage into db wrongly

[Takashi Iwai]

At Fri, 9 Mar 2012 17:07:17 +0800,
Adam Lee wrote:
> 
> On Fri, Mar 09, 2012 at 07:40:27AM +0100, Takashi Iwai wrote:
> > At Fri, 9 Mar 2012 12:22:47 +0800,
> > Adam Lee wrote:
> > > 
> > > Add Vincent in cc, because conky read amixer's result.
> > > 
> > > On Thu, Mar 08, 2012 at 05:45:14PM +0100, Takashi Iwai wrote:
> > > > > * Adam Lee <adam8157 at gmail.com> [2012-03-08 20:36 +0800]:
> > > > > 
> > > > > Package: alsa-utils
> > > > > Version: 1.0.25-1
> > > > > Severity: important
> > > > > 
> > > > > 
> > > > > db is not linear, but amixer believe it is.
> > > > > 
> > > > > "amixer get Master" says "Limits: Playback 0 - 74", then everytime I run
> > > > > "amixer -q sset Master 10%-", there is 8db dec.
> > > > > 
> > > > > For example, at first Master is 100% and 0db, both alsamixer and amixer
> > > > > think it is, and after I run "amixer -q sset Master 10%-", both
> > > > > alsamixer and amixer says Master is -8.00db, but alsamixer says it is
> > > > > 72%, amixer says it is 89%.
> > > > > 
> > > > > alsamixer is right, amixer calc and set wrongly.
> > > > 
> > > > No, both are correct.  You are dreaming too much on the world unified
> > > > percentage representation :)
> > > > 
> > > > The percentage in amixer has nothing to do with dB level.
> > > > It's just the percentage of the raw value range of that mixer
> > > > element.  Thus showing 89% is correct.  It's 10% down from 100%
> > > > (1% is because of the resolution of the raw values).
> > > > 
> > > > Now, alsamixer shows the percentage in a different way.  It's
> > > > explained well in the source code (alsamixer/volume_mapping.c), but
> > > > not mentioned in the man page, unfortunately.
> > > > 
> > > >  * The mapping is designed so that the position in the interval is proportional
> > > >  * to the volume as a human ear would perceive it (i.e., the position is the
> > > >  * cubic root of the linear sample multiplication factor).  For controls with
> > > >  * a small range (24 dB or less), the mapping is linear in the dB values so
> > > >  * that each step has the same size visually.  Only for controls without dB
> > > >  * information, a linear mapping of the hardware volume register values is used
> > > >  * (this is the same algorithm as used in the old alsamixer).
> > > > 
> > > > The percentage representation in alsamixer corresponds to this
> > > > mapping, thus it's neither dB nor linear percent.
> > > > 
> > > 
> > > Hi, Takashi
> > > 
> > > Thank you for replying. But I still insist this is a bug. Three
> > > questions:
> > > 
> > > 1, several months ago, it's OK, both amixer and alsamixer use the human
> > > mapping(0-10% and 90%-100% are the same change by a human ear), why not
> > > now?
> > 
> > amixer hasn't been changed until yet.  It handles either in raw values
> > or in dB.  No human-ear mapping at all.  It's never changed since
> > years, and won't be changed.  If the volume mapping would be
> > implemented to amixer in future, it must be only optional.
> > 
> > Only the recent alsamixer introduced the volume mapping to visualize
> > the volumes reasonably.
> > 
> 
> OK, thank you. Maybe an optional will make everyone happy.
> 
> > > 2, conky(Vincent, I mean ${mixer}), some other software, lot of user's
> > > scripts use amixer to set or get volume, expecting the human mapping,
> > > why change the behavior?
> > 
> > You must be smoking something bad.  The behavior of amixer hasn't been
> > changed.
> > 
> 
> I figured out a reason probably, when the limits range is wide, like
> 0-65536, amixer's mapping and alsamixer's human-ear mapping are close.
> 
> If I remember right, my hardware's limits was 0-65536, but it becomes
> 0-74 after I run "alsactl init", but unfortunately, I don't know how to
> modify it back.
> 
> > > 3, alsamixer and amixer use the same dB value, why there is difference
> > > in percentage? If alsa-utils developer think the human mapping sucks,
> > > why you guys still use it in alsamixer? There is no "both correct", the
> > > difference confuses user...
> > 
> > That's true.  alsamixer should have stopped showing the stupid
> > percentage.
> > 
> > The biggest understand is that people (including you) think there is
> > an absolutely perfect percentage definition for the sound level.  It's
> > an illusion.
> > 
> 
> I don't expect an absolutely perfect percentage definition. I want a
> human-ear mapping, which alsamixer does well, 100% is about as ten times
> loud as 10%.

How did you measure _quantitatively_ it's exactly ten times louder?
And you think 50% is ten times loud as 5% volume, 10% is ten times
loud as 1%?  Things aren't so easy, unfortunately.

> But amixer doesn't work like that, amixer's 100% is about
> as *one hundred times* as amixer's 10%.

Yes, this is what's amixer expected to behave.  It's a value just
representing the percentage of a "raw value" of the mixer element.
It never says it's corresponding to any practical volume.  This is the
misunderstanding first of all.

For example, I guess in your 64k case, the raw value is even not in dB
unit but it's a linear volume.  amixer doesn't care.  10% means only
the 6553 of 65536.  That's all.  So simple.
(In addition, amixer can handle dB, e.g. amixer set Master +10dB or
 such.  But it's not suitable for percentage unit because dB level
 can't be represented in the absolute percent volume -- what is 10% in
 dB?)

> Maybe it is beautiful, and alsamixer's human-ear mapping is stupid in
> the sound science universe. But as a common user, I don't think so. And
> I don't know how you guys put up with it :(

No, you misunderstand what I wrote.  alsamixer's mapping is really an
improvement.  That's why it was implemented recently.  But if it shows
a different number, user may wonder, just like you did.  If you didn't
see a number, you didn't notice the difference :)

But amixer wasn't changed.  amixer is a tool to manipulate raw
values.  Of course, it'd be also nice to implement the same percentage
expression, but as already mentioned, it should be activated only via
an option.  The default behavior of amixer must not be changed for
compatibility reason.


Takashi