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