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

[Tanu Kaskinen]

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

That sounds like a very good idea. Deferring the READY state didn't
occur to me.

-- 
Tanu