Bug in alsa-lib or alsamixer and amixer

Bug in alsa-lib or alsamixer and amixer

[Raymond Yau]

2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 15/06/10 00:43 did gyre and gimble:
> > +12dB(400%) is even larger than the software gain 150% of PA
>
> Software gain of PA 150% = ~+11dB, so not as different as you imply.
>
> I've explained the cubic mapping already, so please don't use arbitrary,
> differently calculated percentages when comparing things. It's like
> comparing apples to oranges.
>
> Col
>
>
When I changed the volume slider of the gnome sound applet ( select
perference ) in Fedora 13 to maximum (i.e. PA 150% )

Seem to be bug in amixer and alsamixer

alsamixer also change to 150% but press any key change back to 100%

The volume range is only from 0 to  65536

why did alsa-lib allow alsa-pulse plugin to set it outside the range ,
alsamixer and amixer also display 150% ?

amixer -D pulse
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 98304 [150%] [on]
  Front Right: Playback 98304 [150%] [on]

Re: Bug in alsa-lib or alsamixer and amixer

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 15/06/10 23:29 did gyre and gimble:
> 2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>
> 
>> 'Twas brillig, and Raymond Yau at 15/06/10 00:43 did gyre and gimble:
>>> +12dB(400%) is even larger than the software gain 150% of PA
>>
>> Software gain of PA 150% = ~+11dB, so not as different as you imply.
>>
>> I've explained the cubic mapping already, so please don't use arbitrary,
>> differently calculated percentages when comparing things. It's like
>> comparing apples to oranges.
>>
>> Col
>>
>>
> When I changed the volume slider of the gnome sound applet ( select
> perference ) in Fedora 13 to maximum (i.e. PA 150% )
> 
> Seem to be bug in amixer and alsamixer
> 
> alsamixer also change to 150% but press any key change back to 100%

The fact that any key changes it back to 100% is kinda expected. It's
not designed to handle values >100% so it makes sense that it clamps it.
Annoying, but it makes sense.

> The volume range is only from 0 to  65536
> 
> why did alsa-lib allow alsa-pulse plugin to set it outside the range ,
> alsamixer and amixer also display 150% ?
> 
> amixer -D pulse
> Simple mixer control 'Master',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 65536
>   Mono:
>   Front Left: Playback 98304 [150%] [on]
>   Front Right: Playback 98304 [150%] [on]


While I agree this could be thought of as a bug, it's actually the
nicest possible display for a system that has no concept of volumes > 100%.

That said, the correct fix would be a nice mechanism for marking the
100% mark. e.g. specifying the limits as a triplet, lower, normal (aka
100%) and max.

AFAIK, no such system is currently in place.

An alternative would be to scale the alsa volume control to the full
range, e.g. make 0 - 98304[1] the range it accepts. But this sucks as
the percentage shown in alsa is not the same as the percentage shown in
other GUIs.

In a practical sense, the current setup is probably less problematic
than the latter suggestion.

Col

[1] FWIW, this precice value will likely change. I've not yet actioned
it but it's likely to be fixed at +11dB which IIRC is slightly above
150%. 11dB is just a figure that we felt was "sensible" with regards to
GUI consistency and I'll try and push this out ot all the UIs I can.


-- 

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: Bug in alsa-lib or alsamixer and amixer

[Raymond Yau]

2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 15/06/10 23:29 did gyre and gimble:
> > 2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>
> >
> >> 'Twas brillig, and Raymond Yau at 15/06/10 00:43 did gyre and gimble:
> >>> +12dB(400%) is even larger than the software gain 150% of PA
> >>
> >> Software gain of PA 150% = ~+11dB, so not as different as you imply.
> >>
> >> I've explained the cubic mapping already, so please don't use arbitrary,
> >> differently calculated percentages when comparing things. It's like
> >> comparing apples to oranges.
> >>
> >> Col
> >>
> >>
> > When I changed the volume slider of the gnome sound applet ( select
> > perference ) in Fedora 13 to maximum (i.e. PA 150% )
> >
> > Seem to be bug in amixer and alsamixer
> >
> > alsamixer also change to 150% but press any key change back to 100%
>
> The fact that any key changes it back to 100% is kinda expected. It's
> not designed to handle values >100% so it makes sense that it clamps it.
> Annoying, but it makes sense.
>

The bug is alsa-lib allow alsa-pulse plugin to set the value 98304 which is
outside 0 - 65536.





>
> > The volume range is only from 0 to  65536
> >
> > why did alsa-lib allow alsa-pulse plugin to set it outside the range ,
> > alsamixer and amixer also display 150% ?
> >
> > amixer -D pulse
> > Simple mixer control 'Master',0
> >   Capabilities: pvolume pswitch pswitch-joined
> >   Playback channels: Front Left - Front Right
> >   Limits: Playback 0 - 65536
> >   Mono:
> >   Front Left: Playback 98304 [150%] [on]
> >   Front Right: Playback 98304 [150%] [on]
>
>
> While I agree this could be thought of as a bug, it's actually the
> nicest possible display for a system that has no concept of volumes > 100%.
>

it is not related to 100% ,

the mixer application use snd_mixer_selem_get_playback_volume_range() to get
min and max to calculate the number of possible step in creating the slider
since the mixer application can only set the volume between min and max by
snd_mixer_selem_set_playback_volume()

The percentage is calculated by dividing the value by (max - min)

Please study ALSA 's simpler api interface

http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html


So this is a bug in alsa-lib which mislead the PA developers

Re: Bug in alsa-lib or alsamixer and amixer

[Raymond Yau]

2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>

> The fact that any key changes it back to 100% is kinda expected. It's
> not designed to handle values >100% so it makes sense that it clamps it.
> Annoying, but it makes sense.
>
> > The volume range is only from 0 to  65536
> >
> > why did alsa-lib allow alsa-pulse plugin to set it outside the range ,
> > alsamixer and amixer also display 150% ?
> >
> > amixer -D pulse
> > Simple mixer control 'Master',0
> >   Capabilities: pvolume pswitch pswitch-joined
> >   Playback channels: Front Left - Front Right
> >   Limits: Playback 0 - 65536
> >   Mono:
> >   Front Left: Playback 98304 [150%] [on]
> >   Front Right: Playback 98304 [150%] [on]
>
>
> While I agree this could be thought of as a bug, it's actually the
> nicest possible display for a system that has no concept of volumes > 100%.
>
> That said, the correct fix would be a nice mechanism for marking the
> 100% mark. e.g. specifying the limits as a triplet, lower, normal (aka
> 100%) and max.
>
> AFAIK, no such system is currently in place.
>
> An alternative would be to scale the alsa volume control to the full
> range, e.g. make 0 - 98304[1] the range it accepts. But this sucks as
> the percentage shown in alsa is not the same as the percentage shown in
> other GUIs.
>
> In a practical sense, the current setup is probably less problematic
> than the latter suggestion.
>
> Col
>
> [1] FWIW, this precice value will likely change. I've not yet actioned
> it but it's likely to be fixed at +11dB which IIRC is slightly above
> 150%. 11dB is just a figure that we felt was "sensible" with regards to
> GUI consistency and I'll try and push this out ot all the UIs I can.
>
>
>
You have made a big mistake , please study the source code of alsamixer and
amixer

Simple mixer control 'PCM',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [12.00dB] [on]
  Front Right: Playback 31 [100%] [12.00dB] [on]


    control.39 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 31'
        comment.dbmin -3450
        comment.dbmax 1200
        iface MIXER
        name 'PCM Playback Volume'
        value.0 31
        value.1 31
    }

---------------------------------------------------------------------

Simple mixer control 'PCM',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 23 [74%] [0.00dB] [on]
  Front Right: Playback 23 [74%] [0.00dB] [on]


    control.39 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 31'
        comment.dbmin -3450
        comment.dbmax 1200
        iface MIXER
        name 'PCM Playback Volume'
        value.0 23
        value.1 23
    }

The percentage displayed below the vertical slider in alsamixer and the
percentage after the dB values are the percentage of the current step / the
total number of step

so you cannot get any percentage > 100% in alsamixer and amixer

snd_mixer_selem_get_playback_volume_range()  of PCM return min =0 and max=
31
at 0dB the percentage is 23/32  about 74%  since 0dB is step 23 in  step 0
-34.5dB , step31 is 12dB (the difference between step is 1.5dB

This percentage in alsamixer and amixer is not those volume scale which you
described  BASE_VOLUME  or PA_NORM

Re: Bug in alsa-lib or alsamixer and amixer

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 16/06/10 07:33 did gyre and gimble:
> 2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>
> 
>> The fact that any key changes it back to 100% is kinda expected. It's
>> not designed to handle values >100% so it makes sense that it clamps it.
>> Annoying, but it makes sense.
>>
>>> The volume range is only from 0 to  65536
>>>
>>> why did alsa-lib allow alsa-pulse plugin to set it outside the range ,
>>> alsamixer and amixer also display 150% ?
>>>
>>> amixer -D pulse
>>> Simple mixer control 'Master',0
>>>   Capabilities: pvolume pswitch pswitch-joined
>>>   Playback channels: Front Left - Front Right
>>>   Limits: Playback 0 - 65536
>>>   Mono:
>>>   Front Left: Playback 98304 [150%] [on]
>>>   Front Right: Playback 98304 [150%] [on]
>>
>>
>> While I agree this could be thought of as a bug, it's actually the
>> nicest possible display for a system that has no concept of volumes > 100%.
>>
>> That said, the correct fix would be a nice mechanism for marking the
>> 100% mark. e.g. specifying the limits as a triplet, lower, normal (aka
>> 100%) and max.
>>
>> AFAIK, no such system is currently in place.
>>
>> An alternative would be to scale the alsa volume control to the full
>> range, e.g. make 0 - 98304[1] the range it accepts. But this sucks as
>> the percentage shown in alsa is not the same as the percentage shown in
>> other GUIs.
>>
>> In a practical sense, the current setup is probably less problematic
>> than the latter suggestion.
>>
>> Col
>>
>> [1] FWIW, this precice value will likely change. I've not yet actioned
>> it but it's likely to be fixed at +11dB which IIRC is slightly above
>> 150%. 11dB is just a figure that we felt was "sensible" with regards to
>> GUI consistency and I'll try and push this out ot all the UIs I can.
>>
>>
>>
> You have made a big mistake , please study the source code of alsamixer and
> amixer

I don't see my "big mistake" to be honest. I'm just describing the
behaviour and stating the fact that I think it's preferable to the
alternatives.

> Simple mixer control 'PCM',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 31
>   Mono:
>   Front Left: Playback 31 [100%] [12.00dB] [on]
>   Front Right: Playback 31 [100%] [12.00dB] [on]
> 
> 
>     control.39 {
>         comment.access 'read write'
>         comment.type INTEGER
>         comment.count 2
>         comment.range '0 - 31'
>         comment.dbmin -3450
>         comment.dbmax 1200
>         iface MIXER
>         name 'PCM Playback Volume'
>         value.0 31
>         value.1 31
>     }
> 
> ---------------------------------------------------------------------
> 
> Simple mixer control 'PCM',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 31
>   Mono:
>   Front Left: Playback 23 [74%] [0.00dB] [on]
>   Front Right: Playback 23 [74%] [0.00dB] [on]
> 
> 
>     control.39 {
>         comment.access 'read write'
>         comment.type INTEGER
>         comment.count 2
>         comment.range '0 - 31'
>         comment.dbmin -3450
>         comment.dbmax 1200
>         iface MIXER
>         name 'PCM Playback Volume'
>         value.0 23
>         value.1 23
>     }

Like much of the content in many of your posts I don't really see why
the above is especially needed but hey....

> The percentage displayed below the vertical slider in alsamixer and the
> percentage after the dB values are the percentage of the current step / the
> total number of step

Right, so the standard definition of a percentage....

> so you cannot get any percentage > 100% in alsamixer and amixer

I know, that's what I said.

> snd_mixer_selem_get_playback_volume_range()  of PCM return min =0 and max=
> 31
> at 0dB the percentage is 23/32  about 74%  since 0dB is step 23 in  step 0
> -34.5dB , step31 is 12dB (the difference between step is 1.5dB

OK, so in short, you'd be of the opinon that we should scale things so
that the alsa mixer %age display is different to that in PA clients.
That's fine, that's your opinion. Personally, I'm off the opposite
opinion but hey.

> This percentage in alsamixer and amixer is not those volume scale which you
> described  BASE_VOLUME  or PA_NORM

It is PA_VOLUME_NORM. When the value is PA_VOLUME_NORM, the alsamixer is
at 100%. When you go above that, alsa cannot handle it (which is fine,
it wasn't designed to).

So as I said in my original mail there two approaches to this. Scale the
full range of PA volumes to the 100% scale and be done with it (tho' PA
allows a significant amount > PA_VOLUME_NORM (although sensible values
are of course limited - like I said before about +11dB/~150% is about as
much as you'd likely want to go) so that PA_VOUME_NORM in alsa != 100%
unlike in PA clients.... or you add the ability to define different
points on the scale in alsa (e.g. min, base, norm, max) where base ==
norm = max when only two are given for backwards compatibility.

That said, I doubt very much it's worth the effort just to maintain
compatibility with the PA plugin... doesn't really seem worth it to me
as it's just a compatibility layer really and most mixer GUIs that care
about pulse (i.e. the ones you should be using on a system that has
pulse enabled) wont use this layer for their mixer functionality anyway.
I certainly wouldn't loose much sleep over it.


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: Bug in alsa-lib or alsamixer and amixer

[Raymond Yau]

2010/6/17 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 16/06/10 07:33 did gyre and gimble:
> > 2010/6/16 Colin Guthrie <gmane@colin.guthr.ie>
> >
> >> The fact that any key changes it back to 100% is kinda expected. It's
> >> not designed to handle values >100% so it makes sense that it clamps it.
> >> Annoying, but it makes sense.
> >>
> >>> The volume range is only from 0 to  65536
> >>>
> >>> why did alsa-lib allow alsa-pulse plugin to set it outside the range ,
> >>> alsamixer and amixer also display 150% ?
> >>>
> >>> amixer -D pulse
> >>> Simple mixer control 'Master',0
> >>>   Capabilities: pvolume pswitch pswitch-joined
> >>>   Playback channels: Front Left - Front Right
> >>>   Limits: Playback 0 - 65536
> >>>   Mono:
> >>>   Front Left: Playback 98304 [150%] [on]
> >>>   Front Right: Playback 98304 [150%] [on]
> >>
> >>
> >> While I agree this could be thought of as a bug, it's actually the
> >> nicest possible display for a system that has no concept of volumes >
> 100%.
> >>
> >> That said, the correct fix would be a nice mechanism for marking the
> >> 100% mark. e.g. specifying the limits as a triplet, lower, normal (aka
> >> 100%) and max.
> >>
> >> AFAIK, no such system is currently in place.
> >>
> >> An alternative would be to scale the alsa volume control to the full
> >> range, e.g. make 0 - 98304[1] the range it accepts. But this sucks as
> >> the percentage shown in alsa is not the same as the percentage shown in
> >> other GUIs.
> >>
> >> In a practical sense, the current setup is probably less problematic
> >> than the latter suggestion.
> >>
> >> Col
> >>
> >> [1] FWIW, this precice value will likely change. I've not yet actioned
> >> it but it's likely to be fixed at +11dB which IIRC is slightly above
> >> 150%. 11dB is just a figure that we felt was "sensible" with regards to
> >> GUI consistency and I'll try and push this out ot all the UIs I can.
> >>
> >>
> >>
> > You have made a big mistake , please study the source code of alsamixer
> and
> > amixer
>
> I don't see my "big mistake" to be honest. I'm just describing the
> behaviour and stating the fact that I think it's preferable to the
> alternatives.
>
> > Simple mixer control 'PCM',0
> >   Capabilities: pvolume pswitch pswitch-joined
> >   Playback channels: Front Left - Front Right
> >   Limits: Playback 0 - 31
> >   Mono:
> >   Front Left: Playback 31 [100%] [12.00dB] [on]
> >   Front Right: Playback 31 [100%] [12.00dB] [on]
> >
> >
> >     control.39 {
> >         comment.access 'read write'
> >         comment.type INTEGER
> >         comment.count 2
> >         comment.range '0 - 31'
> >         comment.dbmin -3450
> >         comment.dbmax 1200
> >         iface MIXER
> >         name 'PCM Playback Volume'
> >         value.0 31
> >         value.1 31
> >     }
> >
> > ---------------------------------------------------------------------
> >
> > Simple mixer control 'PCM',0
> >   Capabilities: pvolume pswitch pswitch-joined
> >   Playback channels: Front Left - Front Right
> >   Limits: Playback 0 - 31
> >   Mono:
> >   Front Left: Playback 23 [74%] [0.00dB] [on]
> >   Front Right: Playback 23 [74%] [0.00dB] [on]
> >
> >
> >     control.39 {
> >         comment.access 'read write'
> >         comment.type INTEGER
> >         comment.count 2
> >         comment.range '0 - 31'
> >         comment.dbmin -3450
> >         comment.dbmax 1200
> >         iface MIXER
> >         name 'PCM Playback Volume'
> >         value.0 23
> >         value.1 23
> >     }
>
> Like much of the content in many of your posts I don't really see why
> the above is especially needed but hey....
>
> > The percentage displayed below the vertical slider in alsamixer and the
> > percentage after the dB values are the percentage of the current step /
> the
> > total number of step
>
> Right, so the standard definition of a percentage....
>
> > so you cannot get any percentage > 100% in alsamixer and amixer
>
> I know, that's what I said.
>
> > snd_mixer_selem_get_playback_volume_range()  of PCM return min =0 and
> max=
> > 31
> > at 0dB the percentage is 23/32  about 74%  since 0dB is step 23 in  step
> 0
> > -34.5dB , step31 is 12dB (the difference between step is 1.5dB
>
> OK, so in short, you'd be of the opinon that we should scale things so
> that the alsa mixer %age display is different to that in PA clients.
> That's fine, that's your opinion. Personally, I'm off the opposite
> opinion but hey.
>
> > This percentage in alsamixer and amixer is not those volume scale which
> you
> > described  BASE_VOLUME  or PA_NORM
>
> It is PA_VOLUME_NORM. When the value is PA_VOLUME_NORM, the alsamixer is
> at 100%. When you go above that, alsa cannot handle it (which is fine,
> it wasn't designed to).
>
> So as I said in my original mail there two approaches to this. Scale the
> full range of PA volumes to the 100% scale and be done with it (tho' PA
> allows a significant amount > PA_VOLUME_NORM (although sensible values
> are of course limited - like I said before about +11dB/~150% is about as
> much as you'd likely want to go) so that PA_VOUME_NORM in alsa != 100%
> unlike in PA clients.... or you add the ability to define different
> points on the scale in alsa (e.g. min, base, norm, max) where base ==
> norm = max when only two are given for backwards compatibility.
>
> That said, I doubt very much it's worth the effort just to maintain
> compatibility with the PA plugin... doesn't really seem worth it to me
> as it's just a compatibility layer really and most mixer GUIs that care
> about pulse (i.e. the ones you should be using on a system that has
> pulse enabled) wont use this layer for their mixer functionality anyway.
> I certainly wouldn't loose much sleep over it.
>
>
> Col
>
>
The bug is alsa-pulse plugin only support step 0 to 65536 steps for the
mixer application

but the mixer application using pulse api can set the volume outside PA_NORM
and pulseaudio server set the step to 98304 which is outside the valid range
of the control

It is either a alsa-pulse bug in delcaring not the full range of the volume
control or the pulseaudio server return the wrong value

Re: Bug in alsa-lib or alsamixer and amixer

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 16/06/10 23:09 did gyre and gimble:
> It is either a alsa-pulse bug in delcaring not the full range of the volume
> control or the pulseaudio server return the wrong value

Dude, I've already explained *exactly* what's up here. I don't really
see it as a problem, but restating over and over certainly isn't going
to change anything.

I can't really be bothered discussing this with you any further as it's
clear your not even reading my replies.

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: Bug in alsa-lib or alsamixer and amixer

[Raymond Yau]

2010/6/17 Colin Guthrie <gmane@colin.guthr.ie>

> 'Twas brillig, and Raymond Yau at 16/06/10 23:09 did gyre and gimble:
> > It is either a alsa-pulse bug in delcaring not the full range of the
> volume
> > control or the pulseaudio server return the wrong value
>
> Dude, I've already explained *exactly* what's up here. I don't really
> see it as a problem, but restating over and over certainly isn't going
> to change anything.
>
> I can't really be bothered discussing this with you any further as it's
> clear your not even reading my replies.
>
> Col
>

The alsamixer was fixed to ensure that control volume values are in their
allowed range

so this is why 98304 was set back to allowed range , but it did not fix the
root cause of the problem

>> But this sucks as
>> the percentage shown in alsa is not the same as the percentage shown in
>> other GUIs.

alsamixer and amixer 's percentage were not designed as your purpose

Have you studied the source code of alsamixer and amixer

the alsa developers have already posted a lot of time in the mailist list ,
they prefer to use dB scale instead of percentage

http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=c9b86f49a8a1a8c337bf0c1b7f12749e8be781ed

Re: Bug in alsa-lib or alsamixer and amixer

[James Courtier-Dutton]

On 17 June 2010 00:34, Raymond Yau <superquad.vortex2@gmail.com> wrote:
> 2010/6/17 Colin Guthrie <gmane@colin.guthr.ie>
>
>
>>> But this sucks as
>>> the percentage shown in alsa is not the same as the percentage shown in
>>> other GUIs.
>
> alsamixer and amixer 's percentage were not designed as your purpose
>
> Have you studied the source code of alsamixer and amixer
>
> the alsa developers have already posted a lot of time in the mailist list ,
> they prefer to use dB scale instead of percentage
>

That is exactly why percentages are bad. One cannot relate one control
to another if one used percentages.
Say that an  audio card had two controls that adjust the gain of the
audio one after the other.
If I set to to 5% above base_volume and the second 5% below
base_volume, would the output be base_volume???
the first 5% might be +5dB, and the second might be -4dB, one does not know.

Whereas, in dB, if one was set to -5dB, and the other set to +5dB, we
would be sure that the accumulative output would have a gain of 0dB.
Percentages are not nor real units at all, dB are.

Kind Regards

James

Re: Bug in alsa-lib or alsamixer and amixer

[Raymond Yau]

2010/6/17 James Courtier-Dutton <james.dutton@gmail.com>

> On 17 June 2010 00:34, Raymond Yau <superquad.vortex2@gmail.com> wrote:
> > 2010/6/17 Colin Guthrie <gmane@colin.guthr.ie>
> >
> >
> >>> But this sucks as
> >>> the percentage shown in alsa is not the same as the percentage shown in
> >>> other GUIs.
> >
> > alsamixer and amixer 's percentage were not designed as your purpose
> >
> > Have you studied the source code of alsamixer and amixer
> >
> > the alsa developers have already posted a lot of time in the mailist list
> ,
> > they prefer to use dB scale instead of percentage
> >
>
> That is exactly why percentages are bad. One cannot relate one control
> to another if one used percentages.
> Say that an  audio card had two controls that adjust the gain of the
> audio one after the other.
> If I set to to 5% above base_volume and the second 5% below
> base_volume, would the output be base_volume???
> the first 5% might be +5dB, and the second might be -4dB, one does not
> know.
>
> Whereas, in dB, if one was set to -5dB, and the other set to +5dB, we
> would be sure that the accumulative output would have a gain of 0dB.
> Percentages are not nor real units at all, dB are.
>
> Kind Regards
>
> James
>

It is because alsamixer and amixer only need to display the "Master" volume
control of one card at a time while pavucontrol and the new version of gnome
volume control have to handle the "Master" volume control when PA switch
sound cards

Different sound cards have different dB rangle for Playback and Capture.

If PA really use decibel range defined in those codec/DAC specification , it
has to resize the slider of the Master Volume control or rescaling the
sliders

To simpify the implementation of the slider ,  a new "PA dB scale" is used
by shift those +12dB(base volume) to 0dB and insist that every sound card 's
minimum_dB is -inf dB ,

This mean that all sound cards will now have same "PA  dB range" , the
volume slider does not need resize or rescaling any more. This is why they
prefer to use percentage to make you believe their calculation of dB is
correct

Re: Bug in alsa-lib or alsamixer and amixer

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 19/06/10 01:39 did gyre and gimble:
> To simpify the implementation of the slider ,  a new "PA dB scale" is used
> by shift those +12dB(base volume) to 0dB and insist that every sound card 's
> minimum_dB is -inf dB ,

No. -inf dB is -inf dB. If the card does not go down to -inf dB, PA will
extend the range in software. If a card only goes down to -12dB minimum
the range -12dB -> -infdB will be done in software. Lennart explained
this very clearly to you already.

> This mean that all sound cards will now have same "PA  dB range" , the
> volume slider does not need resize or rescaling any more. This is why they
> prefer to use percentage to make you believe their calculation of dB is
> correct

WTF? "prefer to use percentage"? What the hell are you talking about?

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/]