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
