Mixer volume/decibel mapping

Mixer volume/decibel mapping

[Sebastian H.]

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.

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

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

Re: Mixer volume/decibel mapping

[James Courtier-Dutton]

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.

Re: Mixer volume/decibel mapping

[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

Re: Mixer volume/decibel mapping

[Sebastian H.]

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

Re: Mixer volume/decibel mapping

[James Courtier-Dutton]

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.

Re: Mixer volume/decibel mapping

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

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 ?

Re: Mixer volume/decibel mapping

[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()

Re: Mixer volume/decibel mapping

[Sebastian H.]

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.

Re: Mixer volume/decibel mapping

[Raymond Yau]

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

Re: Mixer volume/decibel mapping

[Sebastian H.]

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

Re: Mixer volume/decibel mapping

[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

Re: Mixer volume/decibel mapping

[Sebastian Holtermann]

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwN3PIACgkQ75ya6yyQ6VWkYQCfSSPQBuZGL1/mgKgSVKMOjtoR
MI0An3RFPvB8Wxlan682s1Bus00R0FYU
=mh6m
-----END PGP SIGNATURE-----

Re: Mixer volume/decibel mapping

[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=4daf7a0c0b3dd3c2e2ec829ecee8608d04d67773

Re: Mixer volume/decibel mapping

[Sebastian H.]

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=4daf7a0c0b3dd3c2e2ec829ecee8608d04d67773

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.

Re: Mixer volume/decibel mapping

[Sebastian H.]

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

Re: Mixer volume/decibel mapping

[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 ?

Re: Mixer volume/decibel mapping

[Sebastian H.]

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.

Re: Mixer volume/decibel mapping

[Raymond Yau]

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, };

Re: Mixer volume/decibel mapping

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

Re: Mixer volume/decibel mapping

[Raymond Yau]

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

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

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

Re: Mixer volume/decibel mapping

[Peter Ujfalusi]

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

-- 
Péter

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

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

Re: Mixer volume/decibel mapping

[Raymond Yau]

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);

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

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

Re: Mixer volume/decibel mapping

[James Courtier-Dutton]

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????
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

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

Re: Mixer volume/decibel mapping

[Raymond Yau]

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=7c7767ebe2fa847c91a0dd5551ca422aba359473;hp=29fdbec2dcb1ce364812778271056aa9516ff3ed

Re: Mixer volume/decibel mapping

[Colin Guthrie]

'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=7c7767ebe2fa847c91a0dd5551ca422aba359473;hp=29fdbec2dcb1ce364812778271056aa9516ff3ed

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

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Mixer volume/decibel mapping

[Raymond Yau]

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=7c7767ebe2fa847c91a0dd5551ca422aba359473;hp=29fdbec2dcb1ce364812778271056aa9516ff3ed
>
> 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

Re: Mixer volume/decibel mapping

[Raymond Yau]

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;
			}
		}

Re: Mixer volume/decibel mapping

[Colin Guthrie]

'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



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: Mixer volume/decibel mapping

[Raymond Yau]

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

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

Raymond Yau wrote:
> 2010/5/21 Clemens Ladisch <clemens@ladisch.de>
> > 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.
> 
> 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);
> 
> Refer to AK4396 datasheet
> 
> Output Volume
> 
> The AK4396 includes channel independent digital output volumes (ATT) with
> 256 levels at linear step including MUTE.
> These volumes are in front of the DAC and can attenuate the input data from
> 0dB to –48dB and mute.
> 
> dB range is -48dB to 0dB only
> 
> ATT7-0: Attenuation Level
>         ATT = 20 log10 (ATT_DATA / 255) [dB]
>         FFH : 0dB (Default)
>         00H : Mute

This is the section of the datasheet on which the above declarations are
based.

Now if you have some remark or question, you should remember to include
it in your mail.


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Mixer volume/decibel mapping

[Raymond Yau]

2010/5/25 Clemens Ladisch <clemens@ladisch.de>

> Raymond Yau wrote:
> > 2010/5/21 Clemens Ladisch <clemens@ladisch.de>
> > > 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.
> >
> > 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);
> >
> > Refer to AK4396 datasheet
> >
> > Output Volume
> >
> > The AK4396 includes channel independent digital output volumes (ATT) with
> > 256 levels at linear step including MUTE.
> > These volumes are in front of the DAC and can attenuate the input data
> from
> > 0dB to –48dB and mute.
> >
> > dB range is -48dB to 0dB only
> >
> > ATT7-0: Attenuation Level
> >         ATT = 20 log10 (ATT_DATA / 255) [dB]
> >         FFH : 0dB (Default)
> >         00H : Mute
>
> This is the section of the datasheet on which the above declarations are
> based.
>
> Now if you have some remark or question, you should remember to include
> it in your mail.
>
>
> Regards,
> Clemens
>

I have doubt about DECLARE_TLV_DB_LINEAR(ak4396_
db_scale, TLV_DB_GAIN_MUTE, 0);

since the datasheet mention that dB range is only -48dB to 0dB ,  DR and S/N
is only 120dB

ATT = 20 log10 (ATT_DATA / 255) [dB]

How can AK4396 has scale of -inf DB to 0dB in the driver code  ?

BTW , if ymf7xx (DSP) only accept 16 bit digital PCM data and output to
18-20 bit AC97 codec , how can the per stream volume control has a scale
-inf dB to 0dB ?

inf dB may occur  when  DSP accept floating point

however  the storage of Float pointing is still finite , the min dB of DSP
accept FLOAT64 should in theory lower than the min dB of those DSP accept
FLOAT32

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

Raymond Yau wrote:
> I have doubt about DECLARE_TLV_DB_LINEAR(ak4396_db_scale, TLV_DB_GAIN_MUTE, 0);
> 
> since the datasheet mention that dB range is only -48dB to 0dB
> 
> ATT = 20 log10 (ATT_DATA / 255) [dB]
> 
> How can AK4396 has scale of -inf DB to 0dB in the driver code  ?

When ATT_DATA = 0, there is no output, which is an attenuation of -inf.
The next value, ATT_DATA = 1, results in ATT = -48 dB.

> BTW , if ymf7xx (DSP) only accept 16 bit digital PCM data and output to
> 18-20 bit AC97 codec ,

The DSP uses more precise values internally.

> how can the per stream volume control has a scale -inf dB to 0dB ?

multiplication factor 0:  dB = 20 log10(0) = -inf
multiplication factor 1:  dB = 20 log10(1) = 0

This is true regardless of the precision of the multiplier.  Even a one-
bit factor behaves like this; in fact, this would describe a mute switch.


HTH
Clemens

Re: Mixer volume/decibel mapping

[Raymond Yau]

2010/5/25 Clemens Ladisch <clemens@ladisch.de>

> Raymond Yau wrote:
> > I have doubt about DECLARE_TLV_DB_LINEAR(ak4396_db_scale,
> TLV_DB_GAIN_MUTE, 0);
> >
> > since the datasheet mention that dB range is only -48dB to 0dB
> >
> > ATT = 20 log10 (ATT_DATA / 255) [dB]
> >
> > How can AK4396 has scale of -inf DB to 0dB in the driver code  ?
>
> When ATT_DATA = 0, there is no output, which is an attenuation of -inf.
> The next value, ATT_DATA = 1, results in ATT = -48 dB.
>

But snd_mixer_selem_get_playback_dB_range() does not return 48dB
**

Re: Mixer volume/decibel mapping

[Raymond Yau]

2010/5/25 Clemens Ladisch <clemens@ladisch.de>

> Raymond Yau wrote:
>
>
> > BTW , if ymf7xx (DSP) only accept 16 bit digital PCM data and output to
> > 18-20 bit AC97 codec ,
>
> The DSP uses more precise values internally.
>

DSP use more precise values internally only increase the number of step ( dB
per step is much finer resolution , the dB range is limited to the number of
bits of the input digital signral and output digital signal which pass
through ac97 link

There seem to be no hardware can provide infinte dB range

Re: Mixer volume/decibel mapping

[Raymond Yau]

2010/5/25 Clemens Ladisch <clemens@ladisch.de>

> Raymond Yau wrote:
> > I have doubt about DECLARE_TLV_DB_LINEAR(ak4396_db_scale,
> TLV_DB_GAIN_MUTE, 0);
> >
> > since the datasheet mention that dB range is only -48dB to 0dB
> >
> > ATT = 20 log10 (ATT_DATA / 255) [dB]
> >
> > How can AK4396 has scale of -inf DB to 0dB in the driver code  ?
>
> When ATT_DATA = 0, there is no output, which is an attenuation of -inf.
> The next value, ATT_DATA = 1, results in ATT = -48 dB.
>



refer to ice1712/prodigy_hifi.c , why the comment is -64dB to 0dB  ?


/*
 * ak4396 mixers
*/


/*
 * DAC volume attenuation mixer control (-64dB to 0dB)
*/


static int ak4396_dac_vol_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 = 0;   /* mute */
        uinfo->value.integer.max = 0xFF; /* linear */
       return 0;
}



This is true regardless of the precision of the multiplier.  Even a one-
> bit factor behaves like this; in fact, this would describe a mute switch.
>
>
>
This mean that the dB range should be calculated from the next step above
the min_dB and max_dB when min_dB regarded as a mute switch

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

Raymond Yau wrote:
> 2010/5/25 Clemens Ladisch <clemens@ladisch.de>
> > Raymond Yau wrote:
> > > I have doubt about DECLARE_TLV_DB_LINEAR(ak4396_db_scale, TLV_DB_GAIN_MUTE, 0);
> > >
> > > since the datasheet mention that dB range is only -48dB to 0dB
> > >
> > > ATT = 20 log10 (ATT_DATA / 255) [dB]
> > >
> > > How can AK4396 has scale of -inf DB to 0dB in the driver code  ?
> >
> > When ATT_DATA = 0, there is no output, which is an attenuation of -inf.
> > The next value, ATT_DATA = 1, results in ATT = -48 dB.
> 
> refer to ice1712/prodigy_hifi.c , why the comment is -64dB to 0dB  ?
> 
> /*
>  * DAC volume attenuation mixer control (-64dB to 0dB)
> */

Apparently just copied from pontis.c.

> static int ak4396_dac_vol_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 = 0;   /* mute */
>         uinfo->value.integer.max = 0xFF; /* linear */
>        return 0;
> }
> ...
> static const DECLARE_TLV_DB_SCALE(db_scale_wm_dac, -12700, 100, 1);

And this defines a dB scale from -127 dB to +128 dB, which will break
PulseAudio's volume calculations.

> > This is true regardless of the precision of the multiplier.  Even a one-
> > bit factor behaves like this; in fact, this would describe a mute switch.
> 
> This mean that the dB range should be calculated from the next step above
> the min_dB and max_dB when min_dB regarded as a mute switch

No; the AK4396 datasheet mentions -48 dB only because this is the minimum
attenuation that isn't completely mute.  The minimum of the ATT_DATA
registers _is_ zero, i.e. -inf dB, and therefore TLV_DB_GAIN_MUTE is the
correct minimum for the dB range.


Regards,
Clemens

Re: Mixer volume/decibel mapping

[Raymond Yau]

2010/5/28 Clemens Ladisch <clemens@ladisch.de>

> Raymond Yau wrote:
> > 2010/5/25 Clemens Ladisch <clemens@ladisch.de>
> > > Raymond Yau wrote:
> > > > I have doubt about DECLARE_TLV_DB_LINEAR(ak4396_db_scale,
> TLV_DB_GAIN_MUTE, 0);
> > > >
> > > > since the datasheet mention that dB range is only -48dB to 0dB
> > > >
> > > > ATT = 20 log10 (ATT_DATA / 255) [dB]
> > > >
> > > > How can AK4396 has scale of -inf DB to 0dB in the driver code  ?
> > >
> > > When ATT_DATA = 0, there is no output, which is an attenuation of -inf.
> > > The next value, ATT_DATA = 1, results in ATT = -48 dB.
> >
> > refer to ice1712/prodigy_hifi.c , why the comment is -64dB to 0dB  ?
> >
> > /*
> >  * DAC volume attenuation mixer control (-64dB to 0dB)
> > */
>
> Apparently just copied from pontis.c.
>
> > static int ak4396_dac_vol_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 = 0;   /* mute */
> >         uinfo->value.integer.max = 0xFF; /* linear */
> >        return 0;
> > }
> > ...
> > static const DECLARE_TLV_DB_SCALE(db_scale_wm_dac, -12700, 100, 1);
>
> And this defines a dB scale from -127 dB to +128 dB, which will break
> PulseAudio's volume calculations.
>
> > > This is true regardless of the precision of the multiplier.  Even a
> one-
> > > bit factor behaves like this; in fact, this would describe a mute
> switch.
> >
> > This mean that the dB range should be calculated from the next step above
> > the min_dB and max_dB when min_dB regarded as a mute switch
>
> No; the AK4396 datasheet mentions -48 dB only because this is the minimum
> attenuation that isn't completely mute.  The minimum of the ATT_DATA
> registers _is_ zero, i.e. -inf dB, and therefore TLV_DB_GAIN_MUTE is the
> correct minimum for the dB range.
>
>
The AK4396 includes channel independent digital output volumes (ATT) with
256 levels at linear step including MUTE.
These volumes are in front of the DAC and can attenuate the input data from
0dB to –48dB and mute.

It only mention the volume can be attenuate to -48dB and MUTE

some driver are using SMUTE (soft mute) and soft mute enable : default is
OFF

As James said , DB_LINEAR is limited to 0dB as Max , how can you provide a
dB scale for the capture volume control of pulseaudio

Re: Mixer volume/decibel mapping

[James Courtier-Dutton]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Mixer volume/decibel mapping

[Clemens Ladisch]

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

Re: Mixer volume/decibel mapping

[Raymond Yau]

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

Re: Mixer volume/decibel mapping

[Raymond Yau]

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[] = {

Re: Mixer volume/decibel mapping

[Sebastian H.]

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.