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.
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.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
