[Spice-devel] [spice-protocol PATCH v3] volume-sync: spice-protocol, spice-gtk and linux-vdagent

Victor Toso victortoso at redhat.com
Fri Mar 27 09:14:26 PDT 2015


On Fri, Mar 27, 2015 at 03:42:03PM +0100, Victor Toso wrote:
> Hi,
> 
> On Fri, Mar 27, 2015 at 10:23:41AM -0400, Marc-André Lureau wrote:
> >
> > Hi
> >
> > ----- Original Message -----
> > > The volume-sync is done once after agent connects.
> > >
> > > gstreamer backend: we get the volume from the sink/src elements. Even if the
> > > playback/record channels are not created we can start the pipeline and
> > > retrieve
> > > the last/current/default volume from those elements.
> > > Pulsesink and pulsesrc are more common to be used in linux and the retrieved
> > > value for volume/mute are the last of the application which is stored at
> > > $HOME/.config/pulse/random-num-stream-volumes.tdb
> > >
> > > pulse backend: as the communication between application and pulse happens
> > > only
> > > by async calls, if the playback/record channel were not created it's not
> > > possible
> > > to start pulse and retrieve this values sync without using PA threaded as GST
> > > pulse
> > > elements do. For now, spice-pulse become aware of volume changes in the
> > > client which
> > > is enough to solve volume-changes with migration (agent re-connect and the
> > > volume is
> > > sync with client)
> >
> > Right, but is it race free when you just start a session? Couldn't you try
> > to get the current volume while it's not been yet received?
>
> You got me here, I'm not sure about this. AFAIK as spice-pulse uses
> glib-mainloop it should be in the same context, right? I'll take a
> better look into this.

I don't think it may lead to race problems as the call to get volume and
the volume update are handled in the same glib-mainloop.


More information about the Spice-devel mailing list