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

[Tanu Kaskinen]

On Mon, 2015-10-19 at 13:30 +0300, Tanu Kaskinen wrote:
> On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote:
> > * 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.
> 
> > 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.

I probably misunderstood. When you mentioned a flag, I assumed you
meant the stream flag, but maybe you meant using another flag in the
set volume message. That should work. One consideration is that is it
easier to do access control based on the message than based on the
message parameters - we might want to disallow the introspection API
for an application, but still allow the application to set its own
volume. If there's only one "set volume" message used to set both maybe
-absolute and always-relative volumes, an access control policy has to
inspect the message parameters. I would somewhat prefer having separate
messages rather than differentiating with a flag, but that's not a
strong opinion.

Note that there's no "get volume" message anywhere in the protocol.
It's not currently needed, since the "get stream info" message covers
that. If the pa_stream_get_volume() implementation uses a cached
volume, the "get volume" message is not needed in the future either,
because the server will be sending volume update notifications all the
time, so the client never needs to explicitly request the volume.

-- 
Tanu