2010/6/17 Colin Guthrie <gmane@xxxxxxxxxxxxxx>
> 'Twas brillig, and Raymond Yau at 16/06/10 07:33 did gyre and gimble:
> > 2010/6/16 Colin Guthrie <gmane@xxxxxxxxxxxxxx>
> >
> >> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
