[pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.

[Lennart Poettering]

On Thu, 28.05.09 00:53, CJ van den Berg (cj at vdbonline.com) wrote:

> > I am not convinced. Think about this scenario: you have one stream
> > playing. Reference sink volume, virtual sink volume and stream volume
> > are at -inf dB. Now you move stream volume to 0 dB. This would not
> > change the reference volume level, but would set the virtual volume to
> > 0 dB. According to your suggestion the UI would stick to the ref
> > volume, and hence you get *full* output with the UI showing volume at
> > -inf dB. I am pretty sure that people would be confused about that
> > even more than they are with the current logic.
> 
> Well, I think the stream volume should ‘push’ the reference volume. ie.
> if stream volume > reference volume then reference volume == stream
> volume. The would be pretty intuitive if you ask me.

Doesn't work either since this reintroduces all the problems that made
us come up with the concept of the ref volume in the first place:

If a stored volume for a stream says 2 dB more than ref volume, then
when we apply this we will change the ref volume itself (since we need
to 'push' it as you suggest). i.e. before the stream appeared we where
at ref volume x, when it appeared we set the ref volume to x+2dB. Then
when the stream goes away and comes back we'll need to adjust it to
x+4dB and so on which would eventually end up in +inf dB
amplification. Of course, now you probably say that the stored volume
needs to be updated after we restored it, i.e. it would then be 0dB on
disk. However, after we did that, teh stream would from then on be
played at the same level as everything that was stored on disk to be
played at 0dB, i.e. the 2dB difference goes away. Now, your next idea
is probably to update all other stored entries accordingly to even
that out, i.e. when we update the stored entry for our stream we need
to subtract the same dB from *all* db entries --- but if you do that
you end up with something that is 100% equivalent to the current
reference volume logic, with the exception that updating a single ref
volume level is cheap, while updating all entries in the db is
expensive.

We are running in circles.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4