Re: [RFC 00/24] audio: add GStreamer backend

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Dec 01, 2025 at 08:30:26PM +0100, BALATON Zoltan wrote:
> On Mon, 1 Dec 2025, Marc-André Lureau wrote:
> > On Mon, Dec 1, 2025 at 5:03 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > > On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
> > > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > > 
> > > > Hi,
> > > > 
> > > > The following patch series provides a GStreamer-based audio backend,
> > > which could
> > > > ultimately allow QEMU to leverage the framework to support the various
> > > audio
> > > > subsystems and simplify the audio handling logic (timing, resampling,
> > > mixing
> > > > etc), as well as allow greater pipeline flexibility and customization.
> > > 
> > > While it's good to have a GStreamer backend to integrate well into systems
> > > already using that, this should not replace existing audio backends in
> > > QEMU. The reason is that GStreamer has extensive dependencies that I would
> > > 
> > 
> > GStreamer itself is not so big and doesn't have that many dependencies that
> > qemu doesn't already have.
> 
> Except that this proposal uses GStreamer from rust so would also pull in all
> the rust dependencies too which is still not needed for QEMU. Saying that
> it's optional but then you lose audio output is also not quite acceptable.

In terms of replacing the existing audio backends, it would simply have to
wait until we declare Rust to be a mandatory dependency of QEMU, before
proposing any removal of existing backends.

> > > as another audio backend but not as a replacement for QEMU's audio
> > > handling logic and backends.
> > 
> > It would be great if people with very specific or constrained requirements
> > on qemu audio could check if the GStreamer backend fits their need.
> 
> At least one of them already said it wouldn't. Also why somebody not running
> a desktop environment that uses GStreamer would want to add that dependency
> and use a GStreamer plugin to get the sound back to their native sound
> service when it is probably already supported by QEMU directly? QEMU also
> has to support Windows and macOS sound services so having a few more
> Linux/Unix ones does not make it much more complex.

GStreamer is not merely for desktop environments. It is a general purpose
audio system, and in terms of QEMU, it is already used by the Spice server
for video encoding purposes.  IMHO it is reasonable to consider whether
QEMU could use GStreamer for all audio output regardless of whether it is
running from a desktop session or not.

Personally my main concern with gstreamer is that when things go wrong
it can be very difficult to understand why and thus hard to figure out
how to fix it, unless you're pretty experienced with gstreamer.

If we do consider rationalizing how many backends we have, IMHO, it
would be desirable to retain at least one other QEMU audio backend
that is considered simple & reliable (fool proof) to use & debug.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|