[alsa-devel] Bug in alsa-lib or alsamixer and amixer
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]
'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.
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
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
'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
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
'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
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=c9b86f49a8a1a8c337b...
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
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
'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
participants (3)
-
Colin Guthrie -
James Courtier-Dutton -
Raymond Yau