[pulseaudio-discuss] Flat volumes and restoring the app volume

[Colin Guthrie]

'Twas brillig, and Gregory Petrosyan at 30/01/11 15:47 did gyre and gimble:
> Hi,
> 
> Can somebody please explain what flat-volume, actually, is? Strictly
> and concisely, but from user's perspective — not mathematically. Like
> I can explain what non-flat-volume is to anybody :-) I have googled
> quite a bit, but still don't get how it works.

The way I think about it is the simple underlying principle: "Always try
to use the hardware volume controls".

If only one stream is playing and the "System" volume is, 100%, and only
one "Stream" is playing and it's volume is 50%, then set the underlying
hardware controls to "50%" while all the time keeping the (illusion of
the) "System" volume at 100%. The key here is separating the concepts of
the "System" volume and "Hardware" volume - the two are no longer one
and the same.

A more technical solution would be the "Hardware" volume is always
MAX(All Stream Volumes) (except when COUNT(All Streams) == 0, in which
case Hardware Volume == System Volume). System volume is always >=
MAX(All Stream Volumes)


With this in mind, it can be confusing looking at the Hardware volume
(alsamixer -c0) while streams with different Stream Volumes come and go
in PA as it can jump about in a seemingly erratic manner, while PA's
notion of a System volume remains static.

But the key is to break the conceptual connection of System volume to
underlying Hardware volume.

(FWIW, I've used System volume above rather than Sink Volume as I think
it's clearer as an explanation).

> Also, what does m-s-r actually save? Is it "volume the app will have
> if the system volume will be 100%" in case of flat volumes?

IIRC it contains the relative offset from System volume as a factor -
e.g. if System volume increases, so does application. This can be seen
quite easily by simply setting System volume to 75%, and a Stream volume
to 50% (factor of two thirds). Then increase the System volume to 100%
and see how the Stream volume moves to 67%. I think it is this factor
that is actually stored (but I could be wrong).

Looking briefly at the code, it stores a standard pa_cvolume structure
(volume for each channel), but when m-s-r, saves and subsequently
applies the volumes, it does so in non-absolute mode, which means that
it saves the relative ratio and when it's restored, it's multiplied by
the sink's reference volume.

So in the case of the example above, it would be stored is always two
thirds regardless of whether the sink volume itself was changed.

> I am asking these, because I've managed to make an app restore the
> volume properly using ext-stream-restore.h, but when I turn the flat
> volume on, behaviour is counter-intuitive to say at least.

Can you elaborate on this a little? When you say "you've manage to make
an app restore the volume properly using ext-stream-restore.h" what do
you mean? Do you mean you are making an editor for the stream restore
database or are you just meaning that you have an audio producing app
and you are manually using ext-stream-restore.h to get it's saved volume
and are doing something with it manually to set it's own volume?

If the latter, don't do that, the server handles all that for you
automatically. If the former then cool.



I'd have to look further at how the reference_ratio and the reference
volumes themselves work in non-FV mode to give anymore insights but
others may be more familiar with that already without having to poke
around as much as me.

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/]