[Spice-devel] [spice-gtk PATCH v2 3/7] audio: pulse implements spice-audio get functions

Marc-André Lureau mlureau at redhat.com
Mon Mar 23 09:44:43 PDT 2015



----- Original Message -----
> Hey,
> 
> On Mon, Mar 23, 2015 at 09:42:33AM -0400, Marc-André Lureau wrote:
> > Hi
> >
> > ----- Original Message -----
> > > As spice-pulse is aware of client volume changes, it can return the
> > > updated value of volume and mute when requested.
> >
> > Given that you subscribe to events, how do you know if the value is sync or
> > ever set?
> 
> I only care about NEW/CHANGED events in the sink-input/source-output for
> our streams. If the stream was never created, we can't sync as we never
> got the volume value. If the stream was created then we always have the
> last value given by pulseaudio.
> 
> Note that, in this last case, even if we don't have a stream we can
> return the last volume of the last stream created (which is the volume of
> the new stream when it is created)
> 
> >
> > Instead, I would call pa_context_get_{sink_input,source_output}_info().
> > However, it looks all async, I don't know if you can make sync call.
> 
> I don't think is possible unless using the threaded api (like pulsesink
> and pulsesrc in gst-plugins-good) - Then we could 'lock' while the thread
> gets the volume/mute values.
> 
> It is also possible to subscribe/unsubscribe for events when necessary.
> 
> >I guess you need to reenter the loop. Perhaps you should make the SpiceAudio
> >getters async too then.
> >
> 
> Well, that's also possible. Do you think it is the best alternative?

I think the best might be to use the same approach as gstreamer, use a PA thread, and lock the client context. Note, if the gstreamer PA elements are good enough these days (if they correctly modify stream volume), I am all from droping pulse backend and rely on gstreamer instead. What's your opinion about that?


More information about the Spice-devel mailing list