06.08.2014 17:39, I wrote:
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.
After re-reading, I changed my opinion on the proposal. My new opinion is:
The proposed feature has good justification, independent from the web
use case, and should thus be implemented. However, when evaluating its
positioning as a solution to the web browser 100% volume problem, one
should keep in mind that this positioning relies on the "bad idea"
mentioned above (because the root of the evil is that the browser
changes the volume without user interaction). But the same also applies
to Arun's patch. So, at best, when applied to this problem, both
proposals are workarounds.
Still, I prefer Tanu's proposal to be implemented, as it is more general
and has an independent use case.
For a perfect solution to the intra-application mixing problem (aka the
web browser problem, or DirectSound emulation problem), there has to be
a place where the "user is the owner" policy does not apply, and
"application is the owner" policy applies instead. This implies that
this volume factor should not be exposed in external volume control GUIs.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
