[alsa-devel] amixer: convert percentage into db wrongly
severity 663090 normal forwarded 663090 alsa-devel@alsa-project.org thanks
* Adam Lee adam8157@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.
Several months ago, they both right, and I upgraded, and amixer messed up. Please fix it. Thank you.
FYI, my hardware is: "HDA-Intel" "Conexant CX20585" "HDA:14f15069,17aa214c,00100302 HDA:14f12c06,17aa2122,00100000" "0x17aa" "0x215e"
-- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Versions of packages alsa-utils depends on: ii dialog 1.1-20120215-1 ii libasound2 1.0.25-2 ii libc6 2.13-27 ii libncursesw5 5.9-4 ii libsamplerate0 0.1.8-3 ii libtinfo5 5.9-4 ii linux-sound-base 1.0.23+dfsg-4 ii lsb-base 3.2+Debian29 ii module-init-tools 6-1 ii whiptail 0.52.14-8
Versions of packages alsa-utils recommends: ii alsa-base 1.0.23+dfsg-4 ii pciutils 1:3.1.8-2
alsa-utils suggests no packages.
-- no debconf information
Pkg-alsa-devel mailing list Pkg-alsa-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
At Thu, 8 Mar 2012 17:30:02 +0100, Elimar Riesebieter wrote:
severity 663090 normal forwarded 663090 alsa-devel@alsa-project.org thanks
- Adam Lee adam8157@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.
Takashi
Several months ago, they both right, and I upgraded, and amixer messed up. Please fix it. Thank you.
FYI, my hardware is: "HDA-Intel" "Conexant CX20585" "HDA:14f15069,17aa214c,00100302 HDA:14f12c06,17aa2122,00100000" "0x17aa" "0x215e"
-- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Versions of packages alsa-utils depends on: ii dialog 1.1-20120215-1 ii libasound2 1.0.25-2 ii libc6 2.13-27 ii libncursesw5 5.9-4 ii libsamplerate0 0.1.8-3 ii libtinfo5 5.9-4 ii linux-sound-base 1.0.23+dfsg-4 ii lsb-base 3.2+Debian29 ii module-init-tools 6-1 ii whiptail 0.52.14-8
Versions of packages alsa-utils recommends: ii alsa-base 1.0.23+dfsg-4 ii pciutils 1:3.1.8-2
alsa-utils suggests no packages.
-- no debconf information
Pkg-alsa-devel mailing list Pkg-alsa-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
-- The path to source is always uphill! -unknown- _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
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@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?
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?
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...
IMO: Any, any human says 10% plus, she or he definitely wants the human mapping. Maybe you developing guys think there is nothing wrong now, but how about think it from the perspective of user?
Please consider about fixing it, at least discuss it in alsa-utils mail list, thank you.
On Fri, Mar 09, 2012 at 12:22:47PM +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@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?
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?
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...
IMO: Any, any human says 10% plus, she or he definitely wants the human mapping. Maybe you developing guys think there is nothing wrong now, but how about think it from the perspective of user?
Please consider about fixing it, at least discuss it in alsa-utils mail list, thank you.
Sorry for including control@bugs.debian.org in cc. Please remove it when you reply.
And additional info:
I was searching some alternative way to control my volume, but I failed, every script, evert widget uses "amixer set channel xx%(+/-)", like: http://awesome.naquadah.org/wiki/Volume_control_and_display
This means "we user want the human mapping, it works well before. and we wrote tons of scripts using amixer and expecting human mapping".
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@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.
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.
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.
IMO: Any, any human says 10% plus, she or he definitely wants the human mapping. Maybe you developing guys think there is nothing wrong now, but how about think it from the perspective of user?
Please consider about fixing it, at least discuss it in alsa-utils mail list, thank you.
There is no such ML...
Takashi
participants (3)
-
Adam Lee -
Elimar Riesebieter -
Takashi Iwai