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

[Colin Guthrie]

'Twas brillig, and Maarten Bosmans at 09/09/11 08:58 did gyre and gimble:
> Thanks for the explanation, it's a lot clearer now than when you tried
> to do it on IRC.

Phew!

> 2011/9/8 Colin Guthrie <colin at mageia.org>:
>> 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).
> 
> Indeed, I just discovered that I also have such hardware (PCM has 12
> dB of overhead above 0 dB). Do we have any idea how common this is and
> whether most alsa drivers report the dBs correctly now?

You can also quite easily simulate this with HDA by applying e.g. the
following patch:

--- /usr/share/alsa/cards/HDA-Intel.conf.orig	2011-04-26
17:03:37.000000000 +0100
+++ /usr/share/alsa/cards/HDA-Intel.conf	2011-09-08 20:06:56.022413704 +0100
@@ -20,6 +20,9 @@
 			name "PCM Playback Volume"
 			card $CARD
 		}
+		min_dB -46.5
+		max_dB 12.0
+		resolution 32
 	}
 	capture.pcm {
 		type hw


(that's what I did as I don't have any real h/w that has this
configuration).

> I would very much like to have this mode the default (eventually,
> probably not pre-1.0), because it seems a lot more useful to me.

Well this is somewhat tricky. I discussed it at length with Lennart and
he's quite adamant that this config would break as many setups as it
fixes, so while it "makes sense" sometimes, other times it'll cause
people to not hear things loudly enough). I'd suspect that in that later
cases it's due to a broken driver and that's the case we should be
targeting as requiring fixes upstream (i.e. in kernel) rather than the
approach we take now. So while I don't disagree with you, I'm also
unsure as to whether or not it should be default.

>> 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.
> 
> Is a (disabled by default) per user preference enough to make
> applications stop implementing the different volume scale? This looks
> like a candidate for paprefs to me.

Yeah and in actual fact, David's suggestion seemed pretty good overall,
although it would require some additional protocol extensions to expose
it to a client like pavucontrol.

As paprefs is purely a gconf frontend, I don't think it's appropriate to
do it there, but the general principle of exposing it more easily to
users is certainly a valid goal IMO.

Maybe we should hold off until post 1.0 to do such a feature more
thoroughly tho' as adding in a config option which we remove later is
kinda nasty (config parse errors etc unless we keep a deprecated support
for it which is kinda nasty).

> Perhaps, in order to still expose the whole hw volume in the new mode,
> we could make PA_VOLUME_UI_MAX the maximum of the current value and
> the maximum hardware volume setting. (ignoring any implementation
> difficulties for the moment)

I'm not sure. I also considered this, but then that causes
inconsistencies with e.g. different h/w. I think on balance, David's
suggestion could be the winner here, where we just the the user
configure their scale and that's it?

>> 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.
> 
> As David said, this might not be a good thing for sources. Let me
> apply the patch and play with it a bit this weekend.

Yup, this is exactly why I did two options rather than just one.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]