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 <[email protected]> wrote: > > > On Mon, 1 Dec 2025, [email protected] wrote: > > > > From: Marc-André Lureau <[email protected]> > > > > > > > > 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 :|
