[alsa-devel] Mixer volume/decibel mapping
Hello everyone
I'm working on an ALSA-Mixer application for C++/Qt4 and stumbled over volume and decibel mapping for sliders. My question: Is there always an 1 to 1 mapping from volume to decibel and vice versa or can there be decibel values in between two volume steps?
Regards, Sebastian H.
Sebastian H. wrote:
Is there always an 1 to 1 mapping from volume to decibel and vice versa or can there be decibel values in between two volume steps?
The volume values are the device's hardware register values and could have any random dB difference between steps (and that difference might not even be constant over the entire range). The volume/dB mapping just tells you which dB or volume value is nearest to a given volume or dB value.
Regards, Clemens
On 19 May 2010 17:34, Sebastian H. vand2@gmx.de wrote:
Hello everyone
I'm working on an ALSA-Mixer application for C++/Qt4 and stumbled over volume and decibel mapping for sliders. My question: Is there always an 1 to 1 mapping from volume to decibel and vice versa or can there be decibel values in between two volume steps?
There should be a one to one mapping. If the hardware has 200 steps on the volume scale, and those 200 steps are published to the user. With the dB scale, there will still be the same 200 steps in the dB scale. The dB information simply helps the user interface convert each step into a dB value.
2010/5/20 James Courtier-Dutton james.dutton@gmail.com
On 19 May 2010 17:34, Sebastian H. vand2@gmx.de wrote:
Hello everyone
I'm working on an ALSA-Mixer application for C++/Qt4 and stumbled over volume and decibel mapping for sliders. My question: Is there always an 1 to 1 mapping from volume to decibel and
vice
versa or can there be decibel values in between two volume steps?
There should be a one to one mapping. If the hardware has 200 steps on the volume scale, and those 200 steps are published to the user. With the dB scale, there will still be the same 200 steps in the dB scale. The dB information simply helps the user interface convert each step into a dB value.
a stepping function is not continuous and this is why snd_mixer_selem_set_playback_dB() cannot set decibel values in between two volume steps
Am Donnerstag, 20. Mai 2010 10:53:14 schrieb Raymond Yau:
2010/5/20 James Courtier-Dutton james.dutton@gmail.com
On 19 May 2010 17:34, Sebastian H. vand2@gmx.de wrote:
Hello everyone
I'm working on an ALSA-Mixer application for C++/Qt4 and stumbled over volume and decibel mapping for sliders. My question: Is there always an 1 to 1 mapping from volume to decibel and
vice
versa or can there be decibel values in between two volume steps?
There should be a one to one mapping. If the hardware has 200 steps on the volume scale, and those 200 steps are published to the user. With the dB scale, there will still be the same 200 steps in the dB scale. The dB information simply helps the user interface convert each step into a dB value.
a stepping function is not continuous and this is why snd_mixer_selem_set_playback_dB() cannot set decibel values in between two volume steps
That's clear. I imagined that maybe the dB scale could be the "real thing" and the volume steps would be a convenient but possibly coarse mapping into a denser stepped dB space provided by the hardware/driver. This was unlikely but I wanted to ask anyway ;-).
On 20 May 2010 10:41, Sebastian H. vand2@gmx.de wrote:
That's clear. I imagined that maybe the dB scale could be the "real thing" and the volume steps would be a convenient but possibly coarse mapping into a denser stepped dB space provided by the hardware/driver. This was unlikely but I wanted to ask anyway ;-).
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes. The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand. For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values. If implemented, one could then introduce professional gain controls that do not produce "clicks" in the output when adjusted. gain controls with steps in them produce clicks when the gain control is adjusted.
2010/5/21 James Courtier-Dutton james.dutton@gmail.com
On 20 May 2010 10:41, Sebastian H. vand2@gmx.de wrote:
That's clear. I imagined that maybe the dB scale could be the "real thing" and the
volume
steps would be a convenient but possibly coarse mapping into a denser stepped dB space provided by the hardware/driver. This was unlikely but I wanted to ask anyway ;-).
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes. The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand. For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values. If implemented, one could then introduce professional gain controls that do not produce "clicks" in the output when adjusted. gain controls with steps in them produce clicks when the gain control is adjusted.
For example , the 10 band stereo graphic equalizer of au8830 has 32678 steps but the dB range is most likely between -6dB and +6dB
I have not measured the dB values but there is no clipping occur at maximum gain
just compared with the software equalizer alsaequal where you can hear distortion quite easily
snd_vortex_eq_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; uinfo->count = 2; uinfo->value.integer.min = 0x0000; uinfo->value.integer.max = 0x7fff; return 0; }
How can I implement a dB scale for those 10 EQ gain/atten controls ?
2010/5/21 James Courtier-Dutton james.dutton@gmail.com
On 20 May 2010 10:41, Sebastian H. vand2@gmx.de wrote:
That's clear. I imagined that maybe the dB scale could be the "real thing" and the
volume
steps would be a convenient but possibly coarse mapping into a denser stepped dB space provided by the hardware/driver. This was unlikely but I wanted to ask anyway ;-).
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes. The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand. For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values. If implemented, one could then introduce professional gain controls that do not produce "clicks" in the output when adjusted. gain controls with steps in them produce clicks when the gain control is adjusted.
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can the mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Am Freitag, 21. Mai 2010 03:30:20 schrieb Raymond Yau:
2010/5/21 James Courtier-Dutton james.dutton@gmail.com
On 20 May 2010 10:41, Sebastian H. vand2@gmx.de wrote:
That's clear. I imagined that maybe the dB scale could be the "real thing" and the
volume
steps would be a convenient but possibly coarse mapping into a denser stepped dB space provided by the hardware/driver. This was unlikely but I wanted to ask anyway ;-).
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes. The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand. For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values. If implemented, one could then introduce professional gain controls that do not produce "clicks" in the output when adjusted. gain controls with steps in them produce clicks when the gain control is adjusted.
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can the mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the Mixer API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_ functions.
The root issue is that I wondered if the mixer application should offer a separate text input for decibel values besides the text input for volume values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label for dB.
2010/5/21 Sebastian H. vand2@gmx.de
Am Freitag, 21. Mai 2010 03:30:20 schrieb Raymond Yau:
2010/5/21 James Courtier-Dutton james.dutton@gmail.com
On 20 May 2010 10:41, Sebastian H. vand2@gmx.de wrote:
That's clear. I imagined that maybe the dB scale could be the "real thing" and the
volume
steps would be a convenient but possibly coarse mapping into a denser stepped dB space provided by the hardware/driver. This was unlikely but I wanted to ask anyway ;-).
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes. The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand. For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values. If implemented, one could then introduce professional gain controls that do not produce "clicks" in the output when adjusted. gain controls with steps in them produce clicks when the gain control is adjusted.
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can the mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the Mixer API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_ functions.
The root issue is that I wondered if the mixer application should offer a separate text input for decibel values besides the text input for volume values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label for dB.
The main difference between those volume controls using TLV_DB_SCALE and TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and TLV_DB_SCALE has fixed dB value between any two steps.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that there is big difference if he set volume at percentage instead of dB
so it is mainly depend on the scaling of the slider in your mixer application
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/284947
it is not related to ac97 codec but the volume control of DSP which use TLV_DB_SCALE
Am 07.06.2010 05:37, schrieb Raymond Yau:
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can the mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the Mixer API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_ functions.
The root issue is that I wondered if the mixer application should offer a separate text input for decibel values besides the text input for volume values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label for dB.
The main difference between those volume controls using TLV_DB_SCALE and TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and TLV_DB_SCALE has fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that there is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
so it is mainly depend on the scaling of the slider in your mixer application
At the moment the sliders are simply sliding linearly from vol. min. to vol. max. and there is a label which shows the current dB value.
(This made me realize that the neutral (0dB) position of some HDA-Intel record sliders is somwhere in the middle and not at the ends.)
Lately I've been mostly wrestling with the QT4 part of the application and not the ALSA part but I followed this thread loosely.
To say I encoutered some (maybe) bugs with jumping sliders and missing enum values but most of them disappeared after and update from Debian lenny to Debian squeeze. And still the ALSA version of squeeze is probably no the latest. Therefore I did not want to comment on these yet.
Regards, Sebastian
2010/6/7 Sebastian H. vand2@gmx.de
Am 07.06.2010 05:37, schrieb Raymond Yau:
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can
the
mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the
Mixer
API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_
functions.
The root issue is that I wondered if the mixer application should offer
a
separate text input for decibel values besides the text input for volume values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label for
dB.
The main difference between those volume controls using TLV_DB_SCALE and TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and TLV_DB_SCALE
has
fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that
there
is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999 by his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or not
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.06.2010 03:03, schrieb Raymond Yau:
2010/6/7 Sebastian H. vand2@gmx.de
Am 07.06.2010 05:37, schrieb Raymond Yau:
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can
the
mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the
Mixer
API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_
functions.
The root issue is that I wondered if the mixer application should offer
a
separate text input for decibel values besides the text input for volume values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label for
dB.
The main difference between those volume controls using TLV_DB_SCALE and TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and TLV_DB_SCALE
has
fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that
there
is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999 by his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
2010/6/8 Sebastian Holtermann sebholt@web.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.06.2010 03:03, schrieb Raymond Yau:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999
by
his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or
not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
it seem that only "Wave Master" has mute switch , the other "Wave Rear" , "Wave Center/Lfe" and "Wave side" only have volume control
Have you try the patch : emu10k1: allow high-resolution mixer controls
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=4daf7a0c0b3dd3c2e2...
Am 08.06.2010 17:31, schrieb Raymond Yau:
2010/6/8 Sebastian Holtermann sebholt@web.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.06.2010 03:03, schrieb Raymond Yau:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999
by
his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or
not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
it seem that only "Wave Master" has mute switch , the other "Wave Rear" , "Wave Center/Lfe" and "Wave side" only have volume control
Have you try the patch : emu10k1: allow high-resolution mixer controls
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=4daf7a0c0b3dd3c2e2...
alsa-compile.sh did not work out of the box because of "Cannot install kernel sources for unsupported distribution Debian" and I don't have the time to dig deeper into kernel module compiling right now.
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can
the
mixer application know what dB value has been set since the value is in between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the
Mixer
API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_
functions.
The root issue is that I wondered if the mixer application should offer
a
separate text input for decibel values besides the text input for volume values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label for
dB.
The main difference between those volume controls using TLV_DB_SCALE and TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and TLV_DB_SCALE
has
fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that
there
is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999 by his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
(Sorry, I wrote this before with the wrong email address...)
2010/6/8 Sebastian H. vand2@gmx.de
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can
the
mixer application know what dB value has been set since the value is
in
between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the
Mixer
API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_
functions.
The root issue is that I wondered if the mixer application should
offer
a
separate text input for decibel values besides the text input for
volume
values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label
for
dB.
The main difference between those volume controls using TLV_DB_SCALE
and
TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and
TLV_DB_SCALE
has
fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that
there
is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999
by
his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or
not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
Do you ream snd_mixer_selem_get_Playback_dB_range() return 40dB but max_dB - min_dB = 99999.99 dB ?
Am 09.06.2010 07:39, schrieb Raymond Yau:
2010/6/8 Sebastian H. vand2@gmx.de
> I thinks Sebastian's question is whether he can use > snd_mixer_selem_set_playback_ > dB() set any values in between the volume steps > > e.g. Master volume control of ac97 is 1.5 dB per step, > > when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can
the
> mixer application know what dB value has been set since the value is
in
> between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the
Mixer
API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_
functions.
The root issue is that I wondered if the mixer application should
offer
a
separate text input for decibel values besides the text input for
volume
values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label
for
dB.
The main difference between those volume controls using TLV_DB_SCALE
and
TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and
TLV_DB_SCALE
has
fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that
there
is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999
by
his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or
not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
Do you ream snd_mixer_selem_get_Playback_dB_range() return 40dB but max_dB - min_dB = 99999.99 dB ?
e.g. snd_mixer_selem_get_playback_dB_range() for "Wave Surround" returns -40.00 to 0.00 dB and the dB values returned by
snd_mixer_selem_get_playback_dB ( elem, SND_MIXER_SCHN_MONO, &_db_value );
are all in this range except for when the volume ist set to 0. At this and only this volume the returned dB value is out of range with -99999.99 dB. For vol=1 the dB value is -39.60.
2010/6/9 Sebastian H. vand2@gmx.de
Am 09.06.2010 07:39, schrieb Raymond Yau:
2010/6/8 Sebastian H. vand2@gmx.de
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back
-9999999
by
his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or
not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
Do you ream snd_mixer_selem_get_Playback_dB_range() return 40dB but
max_dB -
min_dB = 99999.99 dB ?
e.g. snd_mixer_selem_get_playback_dB_range() for "Wave Surround" returns -40.00 to 0.00 dB and the dB values returned by
snd_mixer_selem_get_playback_dB ( elem, SND_MIXER_SCHN_MONO, &_db_value );
are all in this range except for when the volume ist set to 0. At this and only this volume the returned dB value is out of range with -99999.99 dB. For vol=1 the dB value is -39.60.
accoding to the forumla , 1/100 is -40dB but 0x1571f82/0x8000000 is not 1% so this is driver bug
/* EMU10k1/EMU10k2 DSP control db gain */ static const DECLARE_TLV_DB_SCALE(snd_emu10k1_db_scale1, -4000, 40, 1); static const DECLARE_TLV_DB_LINEAR(snd_emu10k1_db_linear, TLV_DB_GAIN_MUTE, 0);
277 /* dB gain = (float) 20 * log10( float(db_table_value) / 0x8000000 ) */
static const u32 db_table[101] = { 0x00000000, 0x01571f82, 0x01674b41, 0x01783a1b, 0x0189f540, 0x019c8651, 0x01aff763, 0x01c45306, 0x01d9a446, 0x01eff6b8, 0x0207567a, 0x021fd03d, 0x0239714c, 0x02544792, 0x027061a1, 0x028dcebb, 0x02ac9edc, 0x02cce2bf, 0x02eeabe8, 0x03120cb0, 0x0337184e, 0x035de2df, 0x03868173, 0x03b10a18, 0x03dd93e9, 0x040c3713, 0x043d0cea, 0x04702ff3, 0x04a5bbf2, 0x04ddcdfb, 0x0518847f, 0x0555ff62, 0x05966005, 0x05d9c95d, 0x06206005, 0x066a4a52, 0x06b7b067, 0x0708bc4c, 0x075d9a01, 0x07b6779d, 0x08138561, 0x0874f5d5, 0x08dafde1, 0x0945d4ed, 0x09b5b4fd, 0x0a2adad1, 0x0aa58605, 0x0b25f936, 0x0bac7a24, 0x0c3951d8, 0x0ccccccc, 0x0d673b17, 0x0e08f093, 0x0eb24510, 0x0f639481, 0x101d3f2d, 0x10dfa9e6, 0x11ab3e3f, 0x12806ac3, 0x135fa333, 0x144960c5, 0x153e2266, 0x163e6cfe, 0x174acbb7, 0x1863d04d, 0x198a1357, 0x1abe349f, 0x1c00db77, 0x1d52b712, 0x1eb47ee6, 0x2026f30f, 0x21aadcb6, 0x23410e7e, 0x24ea64f9, 0x26a7c71d, 0x287a26c4, 0x2a62812c, 0x2c61df84, 0x2e795779, 0x30aa0bcf, 0x32f52cfe, 0x355bf9d8, 0x37dfc033, 0x3a81dda4, 0x3d43c038, 0x4026e73c, 0x432ce40f, 0x46575af8, 0x49a8040f, 0x4d20ac2a, 0x50c335d3, 0x54919a57, 0x588dead1, 0x5cba514a, 0x611911ea, 0x65ac8c2f, 0x6a773c39, 0x6f7bbc23, 0x74bcc56c, 0x7a3d3272, 0x7fffffff, };
2010/6/8 Sebastian H. vand2@gmx.de
I thinks Sebastian's question is whether he can use snd_mixer_selem_set_playback_ dB() set any values in between the volume steps
e.g. Master volume control of ac97 is 1.5 dB per step,
when using snd_mixer_selem_set_playback_dB() to set -0.9dB , how can
the
mixer application know what dB value has been set since the value is
in
between -1.5dB and 0dB without snd_mixer_selem_get_playbackdB()
Indeed I quite happy with what ALSA already provides (I'm just an interested amateur). My main problem is that there is no documentation for the
Mixer
API and how things are related to each other. Like CTL, HCTL, Mixer and SimpleMixer and of course volume and dB in the snd_mixer_selem_
functions.
The root issue is that I wondered if the mixer application should
offer
a
separate text input for decibel values besides the text input for
volume
values. As pointed out this would not allow for finer grained volume control therefore for the moment I'll probably stick with a mere text label
for
dB.
The main difference between those volume controls using TLV_DB_SCALE
and
TLV_DB_LINEAR is -6dB is at the middle of TLV_DB_LINEAR and
TLV_DB_SCALE
has
fixed dB value between any two steps.
What's TLV_DB_SCALE and TLV_DB_LINEAR for? A grep in the alsa-lib sources did not return anything.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/332631
if the user has both hda onboard sound and emu10k1, he may notice that
there
is big difference if he set volume at percentage instead of dB
Interesting, that's my setup. I have an onboard HDA Intel and a pci SBLive! Card and some el cheapo USB sound cards to experiment with. Thanks I'll give the volume listening test a try at some point.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
Pekka Lampila reported that when he set -40dB and only get back -9999999
by
his program alsa_mixer_test.c
I don't have emu10k1 so don't know whether this is a bug of alsa-lib or
not
I also get a big jump from -39.60dB to -99999.99 dB for some emu10k1 sliders when I move them to the minimum although their advertised minimum is -40dB. This looks like a way to express log ( 0 ).
the emu10k1 driver had removed the "Master" volume control of ac97 codec
"Wave Master" has 100 steps , so the next step above the mute is 20log(1/100)dB = -40dB
i.e the lowest non mute volume of ."Wave Master" volume control of GFR is actually greater than -46.5dB of the "Master Volume control" of ac97
2010/6/7 Sebastian H. vand2@gmx.de
Am 07.06.2010 05:37, schrieb Raymond Yau: At the moment the sliders are simply sliding linearly from vol. min. to vol. max. and there is a label which shows the current dB value.
(This made me realize that the neutral (0dB) position of some HDA-Intel record sliders is somwhere in the middle and not at the ends.)
For capture volume control , there is gain instead of atten
HDA sepcification define the 0dB offset, so the volume range must contain 0dB somewhere
but some driver may not has 0dB within the volume range any more
http://thread.gmane.org/gmane.linux.alsa.devel/73114/focus=73125
James Courtier-Dutton wrote:
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes.
Such controls already exist:
$ grep -rl DB_LINEAR sound/ sound/i2c/other/ak4xxx-adda.c sound/pci/oxygen/hifier.c sound/pci/oxygen/oxygen.c sound/pci/ymfpci/ymfpci_main.c sound/soc/codecs/stac9766.c sound/soc/codecs/wm8350.c sound/soc/codecs/wm8400.c sound/soc/codecs/wm8990.c
The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand.
It is implemented.
For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values.
Which driver is this? It should be changed to use the full range.
Regards, Clemens
Hi,
On Friday 21 May 2010 09:35:31 ext Clemens Ladisch wrote:
James Courtier-Dutton wrote:
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes.
Such controls already exist:
$ grep -rl DB_LINEAR sound/ sound/i2c/other/ak4xxx-adda.c sound/pci/oxygen/hifier.c sound/pci/oxygen/oxygen.c sound/pci/ymfpci/ymfpci_main.c sound/soc/codecs/stac9766.c sound/soc/codecs/wm8350.c sound/soc/codecs/wm8400.c sound/soc/codecs/wm8990.c
The DB_SCALE also provides linear mapping: For example, if the HW volume control has a range 0 .. 100 In HW these means: 0 == -10dB, 1 == -9.8dB, 2 == -9.6dB .. 99 = 9.8dB, 100 = 10dB So it is linear.
#define TLV_DB_LINEAR_ITEM(min_dB, max_dB) #define TLV_DB_SCALE_ITEM(min, step, mute)
The TLV_DB_LINEAR_ITEM(-1000, 1000); is essentially the same as TLV_DB_SCALE_ITEM(-1000, 20, 0); In this case
In linear, you specify the min, and max dB. The control provides the range (steps) in between the two ends. In scale, you specify the minimum, and the steps for each control step. At the end both are linear, and gives you exactly the same volume/dB pair.
The conversion from the control value to a usable value would have to include a user land log operation. It was never implemented due to lack of demand.
It is implemented.
For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values.
Which driver is this? It should be changed to use the full range.
Regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Peter Ujfalusi wrote:
On Friday 21 May 2010 09:35:31 ext Clemens Ladisch wrote:
James Courtier-Dutton wrote:
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes.
Such controls already exist:
$ grep -rl DB_LINEAR sound/ ...
The DB_SCALE also provides linear mapping: For example, if the HW volume control has a range 0 .. 100 In HW these means: 0 == -10dB, 1 == -9.8dB, 2 == -9.6dB .. 99 = 9.8dB, 100 = 10dB So it is linear.
This is not what is meant by "linear", because dB values are not linear.
DB_LINEAR means that the mixer control value is a multiplier for the PCM sample value, as James wrote. A DB_LINEAR mapping has 0 == -infinity dB, full scale == 0 dB, and the mapping between mixer control values and corresponding dB values it _not_ linear.
TLV_DB_LINEAR_ITEM is a quite misleading name, but it actually means "dB mapping for a mixer control whose value has a linear effect on the sound output", _not_ a linear value <-> dB mapping.
Regards, Clemens
2010/5/21 Clemens Ladisch clemens@ladisch.de
Peter Ujfalusi wrote:
On Friday 21 May 2010 09:35:31 ext Clemens Ladisch wrote:
James Courtier-Dutton wrote:
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes.
Such controls already exist:
$ grep -rl DB_LINEAR sound/ ...
The DB_SCALE also provides linear mapping: For example, if the HW volume control has a range 0 .. 100 In HW these means: 0 == -10dB, 1 == -9.8dB, 2 == -9.6dB .. 99 = 9.8dB, 100 = 10dB So it is linear.
This is not what is meant by "linear", because dB values are not linear.
DB_LINEAR means that the mixer control value is a multiplier for the PCM sample value, as James wrote. A DB_LINEAR mapping has 0 == -infinity dB, full scale == 0 dB, and the mapping between mixer control values and corresponding dB values it _not_ linear.
TLV_DB_LINEAR_ITEM is a quite misleading name, but it actually means "dB mapping for a mixer control whose value has a linear effect on the sound output", _not_ a linear value <-> dB mapping.
Regards, Clemens
seem max(full scale) is more then 0dB for some codecs , only three drivers have 0dB as max and TLV_DB_GAIN_MUTE (-99999.99dB) as min
PA 's inf dB is only -200dB
include/tlv.h:#define TLV_DB_GAIN_MUTE -9999999
pci/ymfpci/ymfpci_main.c:static const DECLARE_TLV_DB_LINEAR(db_scale_native, TLV_DB_GAIN_MUTE, 0); pci/oxygen/oxygen.c:static const DECLARE_TLV_DB_LINEAR(ak4396_db_scale, TLV_DB_GAIN_MUTE, 0); pci/oxygen/hifier.c:static const DECLARE_TLV_DB_LINEAR(ak4396_db_scale, TLV_DB_GAIN_MUTE, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, 0, -2100); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); soc/codecs/wm8990.c: 0, 7, TLV_DB_LINEAR_ITEM(-1200, 600), soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, -2100, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); soc/codecs/wm8400.c: 0,7, TLV_DB_LINEAR_ITEM(-1200, 600), soc/codecs/wm8350.c:static DECLARE_TLV_DB_LINEAR(pre_amp_tlv, -1200, 3525); soc/codecs/wm8350.c:static DECLARE_TLV_DB_LINEAR(out_pga_tlv, -5700, 600); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(master_tlv, -4600, 0); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(record_tlv, 0, 2250); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(beep_tlv, -4500, 0); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(mix_tlv, -3450, 1200);
Raymond Yau wrote:
2010/5/21 Clemens Ladisch clemens@ladisch.de
Peter Ujfalusi wrote:
The DB_SCALE also provides linear mapping: For example, if the HW volume control has a range 0 .. 100 In HW these means: 0 == -10dB, 1 == -9.8dB, 2 == -9.6dB .. 99 = 9.8dB, 100 = 10dB So it is linear.
This is not what is meant by "linear", because dB values are not linear.
DB_LINEAR means that the mixer control value is a multiplier for the PCM sample value, as James wrote. A DB_LINEAR mapping has
... in practice ...
0 == -infinity dB, full scale == 0 dB, and the mapping between mixer control values and corresponding dB values it _not_ linear.
TLV_DB_LINEAR_ITEM is a quite misleading name, but it actually means "dB mapping for a mixer control whose value has a linear effect on the sound output", _not_ a linear value <-> dB mapping.
seem max(full scale) is more then 0dB for some codecs , only three drivers have 0dB as max and TLV_DB_GAIN_MUTE (-99999.99dB) as min
And these three are for hardware that use it as a plain multiplier.
All the others seem to be mistakes:
soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(master_tlv, -4600, 0); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(record_tlv, 0, 2250); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(beep_tlv, -4500, 0); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(mix_tlv, -3450, 1200);
These are wrong, both the AC'97 spec and the STAC9766 datasheet say that there is a linear register value/dB mapping; these should all use DECLARE_TLV_DB_SCALE.
soc/codecs/wm8350.c:static DECLARE_TLV_DB_LINEAR(pre_amp_tlv, -1200, 3525); soc/codecs/wm8350.c:static DECLARE_TLV_DB_LINEAR(out_pga_tlv, -5700, 600);
According to the datasheet, these should use DECLARE_TLV_DB_SCALE (like all the others in this file).
soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, -2100, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); soc/codecs/wm8400.c: 0,7, TLV_DB_LINEAR_ITEM(-1200, 600), soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, 0, -2100); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); soc/codecs/wm8990.c: 0, 7, TLV_DB_LINEAR_ITEM(-1200, 600),
Same here.
Regards, Clemens
On 25 May 2010 09:38, Clemens Ladisch clemens@ladisch.de wrote:
Raymond Yau wrote:
2010/5/21 Clemens Ladisch clemens@ladisch.de
Peter Ujfalusi wrote:
The DB_SCALE also provides linear mapping: For example, if the HW volume control has a range 0 .. 100 In HW these means: 0 == -10dB, 1 == -9.8dB, 2 == -9.6dB .. 99 = 9.8dB, 100 = 10dB So it is linear.
This is not what is meant by "linear", because dB values are not linear.
DB_LINEAR means that the mixer control value is a multiplier for the PCM sample value, as James wrote. A DB_LINEAR mapping has
... in practice ...
0 == -infinity dB, full scale == 0 dB, and the mapping between mixer control values and corresponding dB values it _not_ linear.
TLV_DB_LINEAR_ITEM is a quite misleading name, but it actually means "dB mapping for a mixer control whose value has a linear effect on the sound output", _not_ a linear value <-> dB mapping.
seem max(full scale) is more then 0dB for some codecs , only three drivers have 0dB as max and TLV_DB_GAIN_MUTE (-99999.99dB) as min
And these three are for hardware that use it as a plain multiplier.
All the others seem to be mistakes:
soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(master_tlv, -4600, 0); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(record_tlv, 0, 2250); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(beep_tlv, -4500, 0); soc/codecs/stac9766.c:static const DECLARE_TLV_DB_LINEAR(mix_tlv, -3450, 1200);
These are wrong, both the AC'97 spec and the STAC9766 datasheet say that there is a linear register value/dB mapping; these should all use DECLARE_TLV_DB_SCALE.
soc/codecs/wm8350.c:static DECLARE_TLV_DB_LINEAR(pre_amp_tlv, -1200, 3525); soc/codecs/wm8350.c:static DECLARE_TLV_DB_LINEAR(out_pga_tlv, -5700, 600);
According to the datasheet, these should use DECLARE_TLV_DB_SCALE (like all the others in this file).
soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, -2100, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); soc/codecs/wm8400.c:static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); soc/codecs/wm8400.c: 0,7, TLV_DB_LINEAR_ITEM(-1200, 600), soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(rec_mix_tlv, -1500, 600); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(in_pga_tlv, -1650, 3000); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_mix_tlv, 0, -2100); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_pga_tlv, -7300, 600); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_omix_tlv, -600, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_dac_tlv, -7163, 0); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(in_adc_tlv, -7163, 1763); soc/codecs/wm8990.c:static const DECLARE_TLV_DB_LINEAR(out_sidetone_tlv, -3600, 0); soc/codecs/wm8990.c: 0, 7, TLV_DB_LINEAR_ITEM(-1200, 600),
Could this maybe explain why pulseaudio was having such problems with alsa with regards to gain controls????
James Courtier-Dutton wrote:
On 25 May 2010 09:38, Clemens Ladisch clemens@ladisch.de wrote:
All the others seem to be mistakes:
soc/codecs/stac9766.c:... soc/codecs/wm8350.c:... soc/codecs/wm8400.c:... soc/codecs/wm8990.c:...
Could this maybe explain why pulseaudio was having such problems with alsa with regards to gain controls????
Only if it happens on embedded hardware that uses these particular codecs.
Regards, Clemens
2010/5/25 James Courtier-Dutton james.dutton@gmail.com
Could this maybe explain why pulseaudio was having such problems with alsa with regards to gain controls????
I don't think so since no soc user report wrong dB range
http://www.pulseaudio.org/wiki/WritingVolumeControlUIs
If the flat volume model of PA is 0% to 150% , this mean that alsa-lib does not provide any DB scale suitable for PA to implement dB info for the pulse device as DB_LINEAR require max is 0dB ( at least capture stream must have gain )
only one of the PA developer complain about his HDA codec has incorrect dB range but not willing to provide alsa-info.sh
There is a patch which may affect the dB scale
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=7c7767ebe2fa84...
'Twas brillig, and Raymond Yau at 26/05/10 00:24 did gyre and gimble:
only one of the PA developer complain about his HDA codec has incorrect dB range but not willing to provide alsa-info.sh
I presume you mean me :) I had a hunt through the many mails you sent on the previous thread and found such a request I'd obviously missed the first time round. Sorry about that. Not unwilling, just unaware.
I've attached the output to a reply in the other thread.
There is a patch which may affect the dB scale
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=7c7767ebe2fa84...
Interesting. I wonder if this ties in time wise of when I noticed this working..... If I find time to play, I'll maybe try reverting this to see if it helps.
Col
2010/5/27 Colin Guthrie gmane@colin.guthr.ie
'Twas brillig, and Raymond Yau at 26/05/10 00:24 did gyre and gimble:
only one of the PA developer complain about his HDA codec has incorrect
dB
range but not willing to provide alsa-info.sh
I presume you mean me :) I had a hunt through the many mails you sent on the previous thread and found such a request I'd obviously missed the first time round. Sorry about that. Not unwilling, just unaware.
I've attached the output to a reply in the other thread.
There is a patch which may affect the dB scale
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=7c7767ebe2fa84...
Interesting. I wonder if this ties in time wise of when I noticed this working..... If I find time to play, I'll maybe try reverting this to see if it helps.
Col
--
seem not related to your problem
But anyone know why expose -96dB large volume scale can result in in too large scale in percentage representation. ?
since 96dB is the theortical dynamic range of CD audio
2010/5/25 James Courtier-Dutton james.dutton@gmail.com
Could this maybe explain why pulseaudio was having such problems with alsa with regards to gain controls????
Did you answer PA 's developer 's question in FOMS
http://thread.gmane.org/gmane.linux.alsa.devel/50417/focus=50555
what is the answer of this question ?
- That snd_pcm_sw_params_set_start_threshold(.. , (snd_pcm_uframes_t) -1)) disables automatic stopping on underrun.
snd_pcm_uframes_t is unsigned and in snd_pcm_write_areas() pcm/pcm.c
start_threshold seem used as a signed number
is this a special case , what is the difference between 1 and -1 ?
if (state == SND_PCM_STATE_PREPARED) { snd_pcm_sframes_t hw_avail = pcm->buffer_size - avail; hw_avail += frames; /* some plugins might automatically start the stream */ state = snd_pcm_state(pcm); if (state == SND_PCM_STATE_PREPARED && hw_avail >= (snd_pcm_sframes_t) pcm->start_threshold) { err = snd_pcm_start(pcm); if (err < 0) goto _end; } }
'Twas brillig, and Raymond Yau at 29/05/10 02:57 did gyre and gimble:
2010/5/25 James Courtier-Dutton james.dutton@gmail.com
Could this maybe explain why pulseaudio was having such problems with alsa with regards to gain controls????
Did you answer PA 's developer 's question in FOMS
http://thread.gmane.org/gmane.linux.alsa.devel/50417/focus=50555
what is the answer of this question ?
What question? I'm not sure I follow what you're asking here...
- That snd_pcm_sw_params_set_start_threshold(.. , (snd_pcm_uframes_t) -1)) disables automatic stopping on underrun.
snd_pcm_uframes_t is unsigned and in snd_pcm_write_areas() pcm/pcm.c
start_threshold seem used as a signed number
is this a special case , what is the difference between 1 and -1 ?
if (state == SND_PCM_STATE_PREPARED) { snd_pcm_sframes_t hw_avail = pcm->buffer_size - avail; hw_avail += frames; /* some plugins might automatically start the stream */ state = snd_pcm_state(pcm); if (state == SND_PCM_STATE_PREPARED && hw_avail >= (snd_pcm_sframes_t) pcm->start_threshold) { err = snd_pcm_start(pcm); if (err < 0) goto _end; } }
It seems to be used as a signed value there, but I'm not sure if the unsigned -1 case is treated differently in some capacity prior to reaching this code.
The reason -1 is used is just a shortcut to get the maximum value of an unsigned variable. I presume this "as big as possible" case is dealt with appropriately.
I'm absolutely green when it comes to alsa lib API and programming, so you'd be better asking Lennart directly about this.
Col
2010/5/25 Clemens Ladisch clemens@ladisch.de
Raymond Yau wrote:
2010/5/21 Clemens Ladisch clemens@ladisch.de
0 == -infinity dB, full scale == 0 dB, and the mapping between mixer control values and corresponding dB values it _not_ linear.
20 log10 rule
This mean than 0.5 == -6 dB , 0.25 == -12 dB , 0.124 == -24dB . 0.625 == -48dB
I have doubt why PA is at 15% when the volume control of HDA is -48dB
On 21 May 2010 07:35, Clemens Ladisch clemens@ladisch.de wrote:
James Courtier-Dutton wrote:
For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values.
Which driver is this? It should be changed to use the full range.
All creative and emu cards with a DSP. They use a lookup table in the driver.
James Courtier-Dutton wrote:
On 21 May 2010 07:35, Clemens Ladisch clemens@ladisch.de wrote:
James Courtier-Dutton wrote:
For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values.
Which driver is this? It should be changed to use the full range.
All creative and emu cards with a DSP. They use a lookup table in the driver.
Okay, with the latest driver, try: modprobe snd-emu10k1 high_res_gpr_volume=1
I did not yet enable this by default because alsactl has a bug when restoring mixer values saved by the old driver, and alsamixer currently thinks it is a good idea to let you step through two billion values.
Regards, Clemens
2010/5/21 James Courtier-Dutton james.dutton@gmail.com
On 21 May 2010 07:35, Clemens Ladisch clemens@ladisch.de wrote:
James Courtier-Dutton wrote:
For the cards that do have this 32bit linear value, a simple lookup table is used in the kernel code to convert it to 256 step values.
Which driver is this? It should be changed to use the full range.
All creative and emu cards with a DSP. They use a lookup table in the driver.
seem a bug in the lookup table of alsa-lib
20log10(1/100) = -40dB , it should return -40dB if set -40dB
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4883
snd_mixer_selem_set_playback_dB(<master element>, 0, -4000, +1) -> returns 0 snd_mixer_selem_get_playback_dB(<master element>, 0, &value) -> returns 0, sets value to -9999999
2010/5/21 Clemens Ladisch clemens@ladisch.de
James Courtier-Dutton wrote:
I believe it could be extended to support a continuous range. For example, some hardware uses a 32bit value to control the gain. The mix operation is simply "the_sample" * "the_control_value". So in this case the hardware has a linear control that can be considered continuous for our purposes.
Such controls already exist:
$ grep -rl DB_LINEAR sound/ sound/i2c/other/ak4xxx-adda.c sound/pci/oxygen/hifier.c sound/pci/oxygen/oxygen.c sound/pci/ymfpci/ymfpci_main.c sound/soc/codecs/stac9766.c sound/soc/codecs/wm8350.c sound/soc/codecs/wm8400.c sound/soc/codecs/wm8990.c
why is STAC9766 different from other AC97 2.3 codec ?
static const DECLARE_TLV_DB_LINEAR(master_tlv, -4600, 0); static const DECLARE_TLV_DB_LINEAR(record_tlv, 0, 2250); static const DECLARE_TLV_DB_LINEAR(beep_tlv, -4500, 0); static const DECLARE_TLV_DB_LINEAR(mix_tlv, -3450, 1200);
static const struct snd_kcontrol_new stac9766_snd_ac97_controls[] = {
Am Donnerstag, 20. Mai 2010 10:01:37 schrieb James Courtier-Dutton:
There should be a one to one mapping. If the hardware has 200 steps on the volume scale, and those 200 steps are published to the user. With the dB scale, there will still be the same 200 steps in the dB scale. The dB information simply helps the user interface convert each step into a dB value.
Dear James and Clemens
Thank you for the quick response :-). This is the piece of information I was looking for.
Best regards, Sebastian H.
participants (7)
-
Clemens Ladisch -
Colin Guthrie -
James Courtier-Dutton -
Peter Ujfalusi -
Raymond Yau -
Sebastian H. -
Sebastian Holtermann