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

[Victor Toso]

Hi,

On Wed, Mar 25, 2015 at 01:15:32PM -0400, Marc-André Lureau wrote:
> Hi
> 
> ----- Original Message -----
> > 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.
> 
> Bummer.. I wonder how gstreamer apps can provide audio balance then. audiopanorama?

Most likely, yes.
I asked in #gstreamer, volume control per channel is nice-to-have for
the future. It is also possible to deinterleave [0] and use volume element,
but that's not what we want I think :-)

[0] https://blogs.gnome.org/jessevdk/2010/12/17/fun-with-gstreamer-controlling-volume-of-channels-independently/

>
> > 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)
>
> ok, so I guess with gst backend it will always have l=r volume.
>
> perhaps it's not such a showstopper, and we could tentatively deprecate the pulse backend.

I agree, we could use audiopanorama for this until we are capable of
setting volume per channel.

Should I drop the patches for spice-pulse or have it as it is while
deprecating pulse backend?

>
> > 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.
>
> Ok