On Mon, 1 Dec 2025, Daniel P. Berrangé wrote:
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.
But it's most likely found as dependency in apps that already use other
libraries from the same family that usually come with a certain desktop
environment. Also spice does not want to replace all the other display
backends or SDL does not replace other sound backends so the same way it's
fine to add a GStreamer as another optional way to output sound but not as
replacing the existing backends and sound infrastructure in QEMU.
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.
That probably means we should retain at least the lowest level output for
the native sound systems of the OSes where QEMU runs but then we can also
have other backends as the main complexity is in the audio infrastructure
and not in the backends. What may be possible is to drop OSS and the
mixing support that is mainly needed for OSS arguing that ALSA has
replaced OSS on Linux and sndio replaced it on BSD and these can already
do resampling and mixing themselves so this could simplify QEMU audio code
to just pass data to a sound service but I'm not sure this feature isn't
used by some people in QEMU with other backends or to record to wav for
example. If we remove that too saying that recording can be done from the
system native sound service then maybe no need for resampling and mixing
in QEMU at least for output. But what about input where both the system
and the emulated cards are limited to some specific samping rates and they
are not set to use the same? Or do the sound services take care of that
too and you can ask for arbitrary input rate and will it convert from
hardware rate or you get back an error and QEMU has to handle this?
Regards,
BALATON Zoltan
