[pulseaudio-discuss] [PATCH] volumes: Implement options to bypass the base volume system.

[Arun Raghavan]

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