19.10.2015 14:49, Arun Raghavan wrote:
Hi folks,
Thought I'd restart this thread since it's been a while. Let me
summarise the discussion so far.
The idea is that only controlling the stream within the application's
volume slider would have this non-flat behaviour. Mixer applications
such as pavucontrol would not distinguish this stream from other
streams, and changing the volume from there would behave just as any
other stream. This should minimise confusion from users' perspective,
while disabling the mechanism for rogue applications unexpectedly bump
the volume.
This looks like a good proposal overall.
That's how I'd like to see the behaviour work. Now let's talk about
implementation. The previous RFC patch I'd sent communicates the stream
flag for disabling flat volumes to the server, which always disables
flat volumes for that stream. This doesn't work with the behaviour I
described above. So what I think we should do is:
* Streams set a PA_STREAM_DISABLE_FLAT_VOLUME (or
PA_STREAM_PROG_VOLUME_CONTROL or whatever) on the streams for which
they want the new behaviour.
OK.
* We add a new stream volume API -- pa_stream_get_volume(),
pa_stream_set_volume(), pa_stream_set_volume_callback(). I think this
is good to have in general, to have a simpler client API. In the
context of this proposal, this allows us to know when an application is
concerned about the stream volume in the stream context vs. a global
context. (this follow's from Tanu's proposal to deal with applications
that play streams as well as implement their own system mixer -- such
as a browser-based system UI might).
* It is not clear to me at the moment whether the new volume API should
be synchronous. pa_stream_volume_get() should be. I think, but I'm
undecided on pa_stream_set_volume().
This indeed looks simpler than the existing introspection API.
* I'm inclined to keep the implementation of the relative volume
calculation server-side, in order to keep the client library simple. To
do this, pa_stream_volume_get/set() could reuse the same protocol as
the pa_context_* API but set a flag to let the server know the client
wants relative volumes.
I have no opinion here.
* I'd also like to add a policy module to allow blacklisting specific
applications, and forcing this behaviour on them. This will need a
protocol update to set a stream flag after the stream is connected.
* For legacy apps that are not covered by the blacklist we could add an
environment variable that makes all stream and sink-input volume
-related bits to use the new behaviour.
The question here is whether we would later want to force this upon all
sandboxed applications (xdg-app).
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
