[pulseaudio-discuss] Flat volumes and programmatic volume access (again)

[Arun Raghavan]

On Mon, 2015-10-19 at 13:30 +0300, Tanu Kaskinen wrote:
> On Mon, 2015-10-19 at 15:19 +0530, 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 decision to use flat-volumes has certainly been controversial.
> > However, I'm convinced it provides a better user experience than
> > the
> > standard model of having separate per-app and device volumes (even
> > though this is more familiar).
> > 
> > The problem
> 
> I think you meant "a problem" :) Badly behaving applications are not
> the only issue with flat volumes.
> 
> > we face is that some applications set the volume to 100%
> > arbitrarily, and we'd like to avoid having that affect the system
> > volume. Most of the cases where this complaint comes from seems
> > related
> > to applications that allow programmatic access to volume controls
> > (browsers, gnash, etc.).
> > 
> > We discussed a number of solutions in the past, but the one I'd
> > like to
> > take forward is what I'd proposed originally -- a per-stream flag
> > to
> > allow clients to opt out of participating in flat-volume logic. In
> > this
> > way, programs that know they can't make guarantees of being well
> > -behaved. We also need a mechanism to force this on clients that we
> > know aren't well-behaved that we can't change (proprietary and
> > legacy
> > applications).
> > 
> > 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.
> > 
> > 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.
> > 
> > * 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().
> 
> pa_stream_set_volume() should be asynchronous like everything else
> that
> requires a round-trip. pa_stream_get_volume() can be synchronous,
> because we can cache the stream volume in the client, but we need to
> think about what should happen when the client doesn't yet know its
> volume. If the server sends the initial volume in the stream creation
> reply, this problem doesn't exist, but what should happen with old
> servers that don't support that? Could the new API be entirely
> unsupported with older servers? That would mean no volume support in
> clients that don't fall back to the introspection API... Then again,
> maybe it's reasonable to recommend all applications to fall back to
> the
> introspection API for some time, if they don't have guarantees about
> the server version.

I'd rather not have to ask application developers to start worrying
about server version.

We could add some fallback code for older versions to defer emitting
READY on the stream until we query and cache the volume.

> > * I'm inclined to keep the implementation of the relative volume
> > calculation server-side,
> 
> If we want a policy module to be able to enforce the behaviour at the
> server side, I don't see any other way.

That's true indeed, for older clients.

> > 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.
> 
> How is this compatible with the mixer-app-in-browser use case? How
> can
> the mixer app get the absolute volume, if the browser has set the
> relative volume flag for a video app? I think the introspection API
> should stay unaffected by the relative volume flag.

Your next reply clarifies this.

> > * 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.
> 
> I'm not against adding the protocol change just for completeness, but
> I
> also think that the protocol update isn't really necessary. I suppose
> you mean that clients should get notified if the volume flag changes,
> but do clients really need to know? What would they do with the
> knowledge?

You're probably right -- I think this was a leftover from when I was
still considering doing this on the client side, so it should not be
necessary any more. 

> An implementation note: if the flag is altered during the stream
> creation, the final flag value should be sent as part of the stream
> creation reply, not as a separate notification message.

Yup, that's what I had in mind, but it's probably not required any
more.

-- Arun