On 2025-12-02 23:03, BALATON Zoltan wrote:
On Tue, 2 Dec 2025, Paolo Bonzini wrote:
On 12/1/25 21:58, Alexandre Ratchov wrote:
On Mon, Dec 01, 2025 at 10:20:49PM +0400, Marc-André Lureau wrote:
cases. Also when using jack you'd want to have a QEMU backend for
it not
It would be great if people with very specific or constrained
requirements
on qemu audio could check if the GStreamer backend fits their need.
I'm thinking mainly about their simplicity.
Dropping the system API backends would add an extra sophisticated
layer (GStreamer) between the system and the program. In theory, an
unlimited number of software layers may be stacked in a program, but
the more layers there are, the more fragile the program tends to
be. Based on my limited experience, when things went wrong, the
system
backends were simpler to debug and make work than the big frameworks.
IMHO, the system API backends won't hurt GStreamer users, so I see no
reason to remove them.
I mostly agree. Perhaps the DirectSound backend could be removed by
just letting Windows use SDL (unlike macOS, Windows doesn't have a
"native" GUI layer), and the ALSA backend is also not so useful in my
opinion. But all the others have a reason to be there.
ALSA is also useful as the native sound backend for Linux. I'd say it
can already do what pulseaudio or pipewire do so those are not so
useful in my opinion not ALSA. :-)
Regards,
BALATON Zoltan
The PipeWire and PulseAudio backends are used by a large number of users
in the VFIO community. Removing these would be an enormous determent to
QEMU.
Audio output from QEMU has always been problematic, but with the
PulseAudio and later, the PipeWire interface, it became much more user
friendly for those that wanted to configure the VM to output native
audio into their sound plumbing.
I do not agree that ALSA is as useful as you state it is, it's dependent
on the host system's audio hardware support. If the sound device doesn't
support hardware mixing (almost none do anymore), or the bitrate/sample
rate QEMU wishes to use, your out of luck.
What I do think needs fixing here is the removal of the forced S16 audio
format, and the resampler which forces all output to 48KHz. This though
would require changes to the SPICE protocol as currently it is fixed at
two channel 48KHz S16 also IIRC.
IMHO adding GStreamer is unnecessary, we have the modern PipeWire
interface which is compatible with everything. I see absolutely no
reason to add so much complexity to the project for little to no gain.
Regards,
Geoffrey McRae (gnif)
