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

[Victor Toso]

On Mon, Mar 23, 2015 at 12:44:43PM -0400, Marc-André Lureau wrote:
> 
> 
> ----- 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?

I think the gst PA elements are good enough. Since the change from
gst 0.10 to gst 1.0 I've been using gstreamer as default backend and
didn't notice any _new_ problems. But droping pulse entirely is a hard
decision as it affects other applications.

The main difference at the moment to pulse is the volume per channel
which is not available in gststreamvolume and I didn't find a way to
workaround it.

Regarding the volume-sync what is most important is the last volume value
for the application and pulse elements get them from pulse itself so it
works fine IMHO. (i.e you disconnect the client and connect again, it
should have the same volume value as before)

So, if we are keeping pulse I could make it like gstreamer with PA
thread as I too think it the best alternative to work with this async
api.