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

[Geoffrey McRae <geoff@hostfission.com>]

On 2025-12-02 23:44, Marc-André Lureau wrote:
> Hi Geoffrey
> 
> On Tue, Dec 2, 2025 at 4:31 PM Geoffrey McRae
> <geoff@hostfission.com> wrote:
> 
>> 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.
> 
> They come with GStreamer pulse/pipe elements.

Yes, but through another layer of abstraction/complexity with no real 
benefit.

> 
>> 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.
> 
> Could you be more specific?

There are clock sync/drift issues with the emulated hardware device's 
audio clock and the real hardware audio clock. GStreamer won't solve 
this, it requires a tuned PID loop that resamples the audio to 
compensate for the continual drift between the emulated and hardware 
clocks. Without this, over time, the audio can and does get wildly out 
of sync eventually resulting in xruns.

All you have to do is google for "QEMU Crackling Sound". JACK, PipeWire 
and PulseAudio manage to mostly hide (not sovle) this issue from the 
user, but it still occurs. It's worse for SPICE clients as the audio 
gets buffered in the network stack rather then dropped and can lead to 
many seconds of audio latency.

As for applications, we have a large number of people using QEMU/KVM 
with full GPU pass-through for gaming workloads, many of which route the 
QEMU audio into PipeWire/JACK directly which enables the host's sound 
server to perform DSP and mixing, etc.

Others are streaming the guest via Looking Glass for the video feed, and 
using PipeWire from QEMU to feed into OBS for live streaming setups.

The flexibility that JACK & PipeWire bring to the table can not be 
overstated. From a maintenance point of view, JACK and PipeWire are only 
~800 lines of code each, fully self contained and very easy to debug.

All the audio processing/mixing/resampling/routing (and any user 
configured DSP) is fully offloaded to the host's audio server, where it 
should be.

> 
>> 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.
> 
> Why is it a problem that Spice requires 48khz? Afaik, you can't have
> both Spice & another backend (unlike VNC which does monitor to
> capture)

For clients like Looking Glass that take the audio via SPICE for 
rendering locally via it's own audio devices where we do additional 
things such as tracking client/host audio clocks and resample to keep 
the audio latency consistent correcting for the clock drift as mentioned 
prior.

There are quite a lot of people also using virt-viewer with Intel GVT-g 
these days too that are also limited to 48khz S16 again due to it using 
SPICE by default.

I digress though, this is a different topic entirely and I should not 
have raised it here.

> 
>> 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.
> 
> Pipewire alone is not compatible with Windows or OSX, afaik.

Yes, but there is the DirectSound audio driver for Windows, and 
CoreAudio driver for OSX. While I appreciate that DirectSound is 
deprecated, I really think that effort should be put into implementing a 
WASAPI backend for QEMU.

I really do not think that adding all the complexity of GStreamer to 
QEMU is the right way forward. We should just hand off the audio 
processing to the host system's sound server (as we do already), 
whatever it might be, and let it do the heavy lifting.

Regards,
Geoffrey McRae (gnif)