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.
like to avoid and still be able to use QEMU with just an ALSA or SDL audio
backend that are much leaner and provide the needed functionality for most
SDL audio is itself a wrapper for various audio backends, much like
GStreamer in the end, but with arguably less flexibility.
Yes, but as QEMU has SDL for systems where that's supported it could also
have GStreamer as another option but not as the sole option replacing
other backends.
cases. Also when using jack you'd want to have a QEMU backend for it not
going through multiple layers. So adding a GStreamer backend has its use
I wonder what are the advantages of using JACK compared to ALSA, or
pulse/pipewire, tbh.
Jack has capability to route between sources and sinks with low latency
which pulse/pipewire does not have and it allows processing sound better
than using plain ALSA. Jack is useful for example when running sound tools
in virtual machines and want to integrate with host sound tools that
usually support jack. ALSA is useful if you just want to output sound the
simplest way without adding latency or complexity. The other backends are
useful to integrate with other apps/environments using those sound
services.
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.
Regards,
BALATON Zoltan
