On Thu, 2011-09-08 at 21:30 +0100, Colin Guthrie wrote: > When the underlying hardware (typically ALSA) reports that the dB > volume ranges to to a value >0dB, a 'base volume' is automatically > added. This system allows the user to utilise the full range of the > underlying hardware controls (ranging from PA_VOLUME_MIN to > PA_VOLUME_NORM) but still get informed, via UI clues, as to the point > the hardware reports as 0dB (i.e. the point at which your sound should > be unmodified). > > Sadly, this system does not work for some users. Sometimes the range > where the volume remains below the underlying 0dB point is very small > (e.g. from 0 to 20%). In this scenario, things are made very awkward for > users as the active range they typically want to adjust is so small. > > Added to the above scenario, if the user has flat volumes enabled they > will also get this limited range within application volume controls. > > This particular scenario has prompted some applications to implement > their own work arounds to this problem and scale the whole volume range > they expose to the base volume when flat volumes are enabled. This > means that the scale the user sees inside the application will be > different to e.g. the scale given by panel applet volume controls, > OSD displays+volume keys and full blown mixers GUIs. > > This inconsistency in applications is what has prompted this feature. > It allows users to choose whether or not they want to expose the base > volume and get the full range of h/w control (as currently), or whether > they would prefer to honour the 0dB of the underlying h/w and set > that to our 0dB point (aka 100%). UIs which honour PA_VOLUME_UI_MAX will > still offer the user some of the additional range their h/w supports > >0dB. > > The behaviour remains unchanged by default and users will have to set > the feature manually in daemon.conf. The option is split so the user can > choose to apply it separately for sinks (where the problem is most > visible) and sources. IMO this is too large a change for 1.0 and we should only look at this after the release. That said, I think this makes more sense as a per-device option (example: if I to use base_volume for internal mic, but not for my webcam mic). On the UI side, this would be something like a checkbox next to sinks/sources in pavucontrol to "disable hardware amplification" or some such which would cause us to use a (PA_VOLUME_MIN, base_volume) range uniformly. The default would be to use (PA_VOLUME_MIN, PA_VOLUME_NORM). We could then have a way to configure overrides for this default per-device, so in my example above, my internal mic would have a card/model-specific override to forces a (MIN, base_volume) range. Probably needs some fleshing out, but hopefully the basic idea makes sense. Cheers, Arun
