[pulseaudio-discuss] My opinion on Tanu's "second volume control" proposal

[Alexander E. Patrakov]

06.08.2014 17:11, Tanu Kaskinen wrote:
> On Wed, 2014-08-06 at 16:35 +0600, Alexander E. Patrakov wrote:
>> Tanu proposed:
>>
>>> 3) Add a second volume control to streams, one which represents the
>>> stream's own volume only, i.e. never flat volume. Applications that want
>>> to avoid flat volume can use that volume control instead of the primary
>>> volume control.
>>>
>>> Even if proposals 1 and 2 are implemented, I'd still like to implement
>>> proposal 3 too, because it's simple (I need the second volume control at
>>> server side anyway, and adding it to the client API is just a matter of
>>> adding one field to pa_sink_input_info and pa_source_output_info) and
>>> because it provides some new possibilities for applications: for
>>> example, pavucontrol could have an option to not show flat volumes even
>>> when flat volumes are enabled.
>>
>> The idea is well supplanted with a use case, but I think that this could
>> use some more discussion.
>>
>> The potential problem with "just exporting" the field is that the
>> proposal specifies only one additional volume factor with no clear
>> ownership policy, and I am afraid that various agents (the server and
>> the client) will fight over it. OTOH, especially if we design the API to
>> avoid "set this extra volume to this value" operation and only allow
>> relative changes, this may as well be a non-problem.
>
> The ownership policy for the new volume control would be the same as
> with the current stream volume, i.e. the user is the owner, and volume
> changes not originating from user action are most likely a bad idea. I'm
> not sure what kind of fight between agents you're thinking of, but with
> this ownership policy I think there shouldn't be any conflicts any more
> than there is with the current stream volume - stupid applications can
> always fight with the user, but the server will only do what clients ask
> it to do.

OK, I was mistakenly under impression that the "volume changes not 
originating from user action are most likely a bad idea" policy would 
not apply to this second control. But, as it applies, there is indeed no 
fighting.

>
>> Maybe, instead of having one extra volume control, we need to be able to
>> create and destroy additional possibly-invisible volume controls on
>> as-needed basis, with the final extra gain determined by the product of
>> their volumes? E.g., one volume can be used for volume groups, one can
>> be used for ducking when it is in effect, and one for client-specific needs.
>
> We have server-side capability for this already (see
> pa_sink_input.volume_factor_items), what's missing is a way for
> applications to create their own extra volume controls for cases where
> the user-controlled volume is not appropriate. I think this feature can
> and should co-exist with the "second volume control" that I proposed.

I agree.

-- 
Alexander E. Patrakov