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

[Geoffrey McRae <geoff@hostfission.com>]

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)