From: Marc-André Lureau <marcandre.lureau@redhat.com>

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.

The preliminary patches consist of additional cleanups started in QEMU 10.2, in
order to make the code more modular and use QOM.

Finally, the last patch introduces the "audio" rust crate that implements the
GStreamer backend. See the TODO list in the commit message for the remaining or
related work items.

Please review and test!

Based-on: https://gitlab.com/bonzini/qemu.git rust-cargo
Requires meson from https://github.com/bonzini/meson.git cargo-object-full

Marc-André Lureau (24):
  rust: patch thiserror to work with meson
  audio: remove obsolete/obscure functions
  audio/dbus: make "dbus" the default backend when using -display dbus
  qemu-options.hx: clarify default audio backend selection
  audio: introduce AudioDriver
  audio: simplify audio_init()
  audio: move object creation to audio_driver_init()
  audio: add QOM module-objects for each backend
  audio: remove set_dbus_server from audio_driver
  audio: lookup "audio-" object types, and realize them
  audio: switch to module-object, drop audio driver registration
  module: remove audio module support
  audio: keep a strong reference on the backend
  audio: make list type declaration private
  audio: make create_pdos() private
  replay: remove dependency on audio/
  audio: make all the backend-specific APIs take the be
  audio: make AudioBackend truely abstract
  audio: split AudioBackend
  audio: AUD_ -> audio_be_
  audio-be: add common pre-conditions
  audio-be: add some state trace
  audio: split AudioDriver code in audio-driver.c
  WIP: rust/audio: add GStreamer backend

 qapi/audio.json                               |   29 +
 ...dio_template.h => audio-driver_template.h} |   76 +-
 audio/audio_int.h                             |   50 +-
 include/qemu/audio-capture.h                  |   24 +-
 include/qemu/audio.h                          |  129 +-
 include/qemu/module.h                         |    3 +-
 include/system/replay.h                       |    8 +-
 replay/replay-internal.h                      |    2 +
 rust/audio/wrapper.h                          |   27 +
 audio/alsaaudio.c                             |   42 +-
 audio/audio-be.c                              |  276 ++
 audio/audio-driver.c                          | 1988 +++++++++++++++
 audio/audio.c                                 | 2248 ++---------------
 audio/dbusaudio.c                             |   57 +-
 audio/dsoundaudio.c                           |   37 +-
 audio/jackaudio.c                             |   37 +-
 audio/noaudio.c                               |   37 +-
 audio/ossaudio.c                              |   41 +-
 audio/paaudio.c                               |   37 +-
 audio/pwaudio.c                               |   37 +-
 audio/sdlaudio.c                              |   37 +-
 audio/sndioaudio.c                            |   37 +-
 audio/spiceaudio.c                            |   37 +-
 audio/wavaudio.c                              |   37 +-
 audio/wavcapture.c                            |    7 +-
 hw/audio/ac97.c                               |   42 +-
 hw/audio/adlib.c                              |   29 +-
 hw/audio/asc.c                                |   20 +-
 hw/audio/cs4231a.c                            |   18 +-
 hw/audio/es1370.c                             |   26 +-
 hw/audio/gus.c                                |   11 +-
 hw/audio/hda-codec.c                          |   26 +-
 hw/audio/lm4549.c                             |   20 +-
 hw/audio/pcspk.c                              |    8 +-
 hw/audio/sb16.c                               |   22 +-
 hw/audio/via-ac97.c                           |   20 +-
 hw/audio/virtio-snd.c                         |   36 +-
 hw/audio/wm8750.c                             |   42 +-
 hw/display/xlnx_dp.c                          |   14 +-
 hw/usb/dev-audio.c                            |   18 +-
 replay/replay-audio.c                         |   51 +-
 replay/replay.c                               |    2 +-
 replay/stubs-system.c                         |    8 +-
 ui/dbus.c                                     |   16 +-
 ui/vnc.c                                      |    4 +-
 Cargo.lock                                    |  572 ++++-
 Cargo.toml                                    |    6 +
 audio/coreaudio.m                             |   37 +-
 audio/meson.build                             |    2 +
 audio/trace-events                            |    9 +
 qemu-options.hx                               |   20 +-
 rust/audio/Cargo.toml                         |   29 +
 rust/audio/build.rs                           |   49 +
 rust/audio/meson.build                        |   75 +
 rust/audio/src/audio.rs                       |  516 ++++
 rust/audio/src/bindings.rs                    |   32 +
 rust/audio/src/gstreamer.rs                   | 1070 ++++++++
 rust/audio/src/lib.rs                         |   99 +
 rust/meson.build                              |    6 +
 .../packagefiles/syn-2-rs/meson/meson.build   |    3 +
 .../thiserror-2.0.17-include.patch            |   14 +
 .../thiserror-impl-2.0.17-include.patch       |   13 +
 subprojects/syn-2-rs.wrap                     |   11 +-
 subprojects/thiserror-2-rs.wrap               |   10 +
 subprojects/thiserror-impl-2-rs.wrap          |   10 +
 65 files changed, 5862 insertions(+), 2494 deletions(-)
 rename audio/{audio_template.h => audio-driver_template.h} (90%)
 create mode 100644 rust/audio/wrapper.h
 create mode 100644 audio/audio-be.c
 create mode 100644 audio/audio-driver.c
 create mode 100644 rust/audio/Cargo.toml
 create mode 100644 rust/audio/build.rs
 create mode 100644 rust/audio/meson.build
 create mode 100644 rust/audio/src/audio.rs
 create mode 100644 rust/audio/src/bindings.rs
 create mode 100644 rust/audio/src/gstreamer.rs
 create mode 100644 rust/audio/src/lib.rs
 create mode 100644 subprojects/packagefiles/syn-2-rs/meson/meson.build
 create mode 100644 subprojects/packagefiles/thiserror-2.0.17-include.patch
 create mode 100644 subprojects/packagefiles/thiserror-impl-2.0.17-include.patch
 create mode 100644 subprojects/thiserror-2-rs.wrap
 create mode 100644 subprojects/thiserror-impl-2-rs.wrap

-- 
2.51.1

On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> 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 
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 
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 
as another audio backend but not as a replacement for QEMU's audio 
handling logic and backends.

Regards,
BALATON Zoltan

> The preliminary patches consist of additional cleanups started in QEMU 10.2, in
> order to make the code more modular and use QOM.
>
> Finally, the last patch introduces the "audio" rust crate that implements the
> GStreamer backend. See the TODO list in the commit message for the remaining or
> related work items.
>
> Please review and test!
>
> Based-on: https://gitlab.com/bonzini/qemu.git rust-cargo
> Requires meson from https://github.com/bonzini/meson.git cargo-object-full
>
> Marc-André Lureau (24):
>  rust: patch thiserror to work with meson
>  audio: remove obsolete/obscure functions
>  audio/dbus: make "dbus" the default backend when using -display dbus
>  qemu-options.hx: clarify default audio backend selection
>  audio: introduce AudioDriver
>  audio: simplify audio_init()
>  audio: move object creation to audio_driver_init()
>  audio: add QOM module-objects for each backend
>  audio: remove set_dbus_server from audio_driver
>  audio: lookup "audio-" object types, and realize them
>  audio: switch to module-object, drop audio driver registration
>  module: remove audio module support
>  audio: keep a strong reference on the backend
>  audio: make list type declaration private
>  audio: make create_pdos() private
>  replay: remove dependency on audio/
>  audio: make all the backend-specific APIs take the be
>  audio: make AudioBackend truely abstract
>  audio: split AudioBackend
>  audio: AUD_ -> audio_be_
>  audio-be: add common pre-conditions
>  audio-be: add some state trace
>  audio: split AudioDriver code in audio-driver.c
>  WIP: rust/audio: add GStreamer backend
>
> qapi/audio.json                               |   29 +
> ...dio_template.h => audio-driver_template.h} |   76 +-
> audio/audio_int.h                             |   50 +-
> include/qemu/audio-capture.h                  |   24 +-
> include/qemu/audio.h                          |  129 +-
> include/qemu/module.h                         |    3 +-
> include/system/replay.h                       |    8 +-
> replay/replay-internal.h                      |    2 +
> rust/audio/wrapper.h                          |   27 +
> audio/alsaaudio.c                             |   42 +-
> audio/audio-be.c                              |  276 ++
> audio/audio-driver.c                          | 1988 +++++++++++++++
> audio/audio.c                                 | 2248 ++---------------
> audio/dbusaudio.c                             |   57 +-
> audio/dsoundaudio.c                           |   37 +-
> audio/jackaudio.c                             |   37 +-
> audio/noaudio.c                               |   37 +-
> audio/ossaudio.c                              |   41 +-
> audio/paaudio.c                               |   37 +-
> audio/pwaudio.c                               |   37 +-
> audio/sdlaudio.c                              |   37 +-
> audio/sndioaudio.c                            |   37 +-
> audio/spiceaudio.c                            |   37 +-
> audio/wavaudio.c                              |   37 +-
> audio/wavcapture.c                            |    7 +-
> hw/audio/ac97.c                               |   42 +-
> hw/audio/adlib.c                              |   29 +-
> hw/audio/asc.c                                |   20 +-
> hw/audio/cs4231a.c                            |   18 +-
> hw/audio/es1370.c                             |   26 +-
> hw/audio/gus.c                                |   11 +-
> hw/audio/hda-codec.c                          |   26 +-
> hw/audio/lm4549.c                             |   20 +-
> hw/audio/pcspk.c                              |    8 +-
> hw/audio/sb16.c                               |   22 +-
> hw/audio/via-ac97.c                           |   20 +-
> hw/audio/virtio-snd.c                         |   36 +-
> hw/audio/wm8750.c                             |   42 +-
> hw/display/xlnx_dp.c                          |   14 +-
> hw/usb/dev-audio.c                            |   18 +-
> replay/replay-audio.c                         |   51 +-
> replay/replay.c                               |    2 +-
> replay/stubs-system.c                         |    8 +-
> ui/dbus.c                                     |   16 +-
> ui/vnc.c                                      |    4 +-
> Cargo.lock                                    |  572 ++++-
> Cargo.toml                                    |    6 +
> audio/coreaudio.m                             |   37 +-
> audio/meson.build                             |    2 +
> audio/trace-events                            |    9 +
> qemu-options.hx                               |   20 +-
> rust/audio/Cargo.toml                         |   29 +
> rust/audio/build.rs                           |   49 +
> rust/audio/meson.build                        |   75 +
> rust/audio/src/audio.rs                       |  516 ++++
> rust/audio/src/bindings.rs                    |   32 +
> rust/audio/src/gstreamer.rs                   | 1070 ++++++++
> rust/audio/src/lib.rs                         |   99 +
> rust/meson.build                              |    6 +
> .../packagefiles/syn-2-rs/meson/meson.build   |    3 +
> .../thiserror-2.0.17-include.patch            |   14 +
> .../thiserror-impl-2.0.17-include.patch       |   13 +
> subprojects/syn-2-rs.wrap                     |   11 +-
> subprojects/thiserror-2-rs.wrap               |   10 +
> subprojects/thiserror-impl-2-rs.wrap          |   10 +
> 65 files changed, 5862 insertions(+), 2494 deletions(-)
> rename audio/{audio_template.h => audio-driver_template.h} (90%)
> create mode 100644 rust/audio/wrapper.h
> create mode 100644 audio/audio-be.c
> create mode 100644 audio/audio-driver.c
> create mode 100644 rust/audio/Cargo.toml
> create mode 100644 rust/audio/build.rs
> create mode 100644 rust/audio/meson.build
> create mode 100644 rust/audio/src/audio.rs
> create mode 100644 rust/audio/src/bindings.rs
> create mode 100644 rust/audio/src/gstreamer.rs
> create mode 100644 rust/audio/src/lib.rs
> create mode 100644 subprojects/packagefiles/syn-2-rs/meson/meson.build
> create mode 100644 subprojects/packagefiles/thiserror-2.0.17-include.patch
> create mode 100644 subprojects/packagefiles/thiserror-impl-2.0.17-include.patch
> create mode 100644 subprojects/thiserror-2-rs.wrap
> create mode 100644 subprojects/thiserror-impl-2-rs.wrap
>
>

Hi

On Mon, Dec 1, 2025 at 5:03 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > 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.


> 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.


> 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.


> 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.


>
> Regards,
> BALATON Zoltan
>
> > The preliminary patches consist of additional cleanups started in QEMU
> 10.2, in
> > order to make the code more modular and use QOM.
> >
> > Finally, the last patch introduces the "audio" rust crate that
> implements the
> > GStreamer backend. See the TODO list in the commit message for the
> remaining or
> > related work items.
> >
> > Please review and test!
> >
> > Based-on: https://gitlab.com/bonzini/qemu.git rust-cargo
> > Requires meson from https://github.com/bonzini/meson.git
> cargo-object-full
> >
> > Marc-André Lureau (24):
> >  rust: patch thiserror to work with meson
> >  audio: remove obsolete/obscure functions
> >  audio/dbus: make "dbus" the default backend when using -display dbus
> >  qemu-options.hx: clarify default audio backend selection
> >  audio: introduce AudioDriver
> >  audio: simplify audio_init()
> >  audio: move object creation to audio_driver_init()
> >  audio: add QOM module-objects for each backend
> >  audio: remove set_dbus_server from audio_driver
> >  audio: lookup "audio-" object types, and realize them
> >  audio: switch to module-object, drop audio driver registration
> >  module: remove audio module support
> >  audio: keep a strong reference on the backend
> >  audio: make list type declaration private
> >  audio: make create_pdos() private
> >  replay: remove dependency on audio/
> >  audio: make all the backend-specific APIs take the be
> >  audio: make AudioBackend truely abstract
> >  audio: split AudioBackend
> >  audio: AUD_ -> audio_be_
> >  audio-be: add common pre-conditions
> >  audio-be: add some state trace
> >  audio: split AudioDriver code in audio-driver.c
> >  WIP: rust/audio: add GStreamer backend
> >
> > qapi/audio.json                               |   29 +
> > ...dio_template.h => audio-driver_template.h} |   76 +-
> > audio/audio_int.h                             |   50 +-
> > include/qemu/audio-capture.h                  |   24 +-
> > include/qemu/audio.h                          |  129 +-
> > include/qemu/module.h                         |    3 +-
> > include/system/replay.h                       |    8 +-
> > replay/replay-internal.h                      |    2 +
> > rust/audio/wrapper.h                          |   27 +
> > audio/alsaaudio.c                             |   42 +-
> > audio/audio-be.c                              |  276 ++
> > audio/audio-driver.c                          | 1988 +++++++++++++++
> > audio/audio.c                                 | 2248 ++---------------
> > audio/dbusaudio.c                             |   57 +-
> > audio/dsoundaudio.c                           |   37 +-
> > audio/jackaudio.c                             |   37 +-
> > audio/noaudio.c                               |   37 +-
> > audio/ossaudio.c                              |   41 +-
> > audio/paaudio.c                               |   37 +-
> > audio/pwaudio.c                               |   37 +-
> > audio/sdlaudio.c                              |   37 +-
> > audio/sndioaudio.c                            |   37 +-
> > audio/spiceaudio.c                            |   37 +-
> > audio/wavaudio.c                              |   37 +-
> > audio/wavcapture.c                            |    7 +-
> > hw/audio/ac97.c                               |   42 +-
> > hw/audio/adlib.c                              |   29 +-
> > hw/audio/asc.c                                |   20 +-
> > hw/audio/cs4231a.c                            |   18 +-
> > hw/audio/es1370.c                             |   26 +-
> > hw/audio/gus.c                                |   11 +-
> > hw/audio/hda-codec.c                          |   26 +-
> > hw/audio/lm4549.c                             |   20 +-
> > hw/audio/pcspk.c                              |    8 +-
> > hw/audio/sb16.c                               |   22 +-
> > hw/audio/via-ac97.c                           |   20 +-
> > hw/audio/virtio-snd.c                         |   36 +-
> > hw/audio/wm8750.c                             |   42 +-
> > hw/display/xlnx_dp.c                          |   14 +-
> > hw/usb/dev-audio.c                            |   18 +-
> > replay/replay-audio.c                         |   51 +-
> > replay/replay.c                               |    2 +-
> > replay/stubs-system.c                         |    8 +-
> > ui/dbus.c                                     |   16 +-
> > ui/vnc.c                                      |    4 +-
> > Cargo.lock                                    |  572 ++++-
> > Cargo.toml                                    |    6 +
> > audio/coreaudio.m                             |   37 +-
> > audio/meson.build                             |    2 +
> > audio/trace-events                            |    9 +
> > qemu-options.hx                               |   20 +-
> > rust/audio/Cargo.toml                         |   29 +
> > rust/audio/build.rs                           |   49 +
> > rust/audio/meson.build                        |   75 +
> > rust/audio/src/audio.rs                       |  516 ++++
> > rust/audio/src/bindings.rs                    |   32 +
> > rust/audio/src/gstreamer.rs                   | 1070 ++++++++
> > rust/audio/src/lib.rs                         |   99 +
> > rust/meson.build                              |    6 +
> > .../packagefiles/syn-2-rs/meson/meson.build   |    3 +
> > .../thiserror-2.0.17-include.patch            |   14 +
> > .../thiserror-impl-2.0.17-include.patch       |   13 +
> > subprojects/syn-2-rs.wrap                     |   11 +-
> > subprojects/thiserror-2-rs.wrap               |   10 +
> > subprojects/thiserror-impl-2-rs.wrap          |   10 +
> > 65 files changed, 5862 insertions(+), 2494 deletions(-)
> > rename audio/{audio_template.h => audio-driver_template.h} (90%)
> > create mode 100644 rust/audio/wrapper.h
> > create mode 100644 audio/audio-be.c
> > create mode 100644 audio/audio-driver.c
> > create mode 100644 rust/audio/Cargo.toml
> > create mode 100644 rust/audio/build.rs
> > create mode 100644 rust/audio/meson.build
> > create mode 100644 rust/audio/src/audio.rs
> > create mode 100644 rust/audio/src/bindings.rs
> > create mode 100644 rust/audio/src/gstreamer.rs
> > create mode 100644 rust/audio/src/lib.rs
> > create mode 100644 subprojects/packagefiles/syn-2-rs/meson/meson.build
> > create mode 100644
> subprojects/packagefiles/thiserror-2.0.17-include.patch
> > create mode 100644
> subprojects/packagefiles/thiserror-impl-2.0.17-include.patch
> > create mode 100644 subprojects/thiserror-2-rs.wrap
> > create mode 100644 subprojects/thiserror-impl-2-rs.wrap
> >
> >

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
> > 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 can connect programs with deterministic latency. My wild guess is
that it would be to run a synths in the vm.

> > 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.

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.

My 2 cents.

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.

Paolo

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

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)

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.


>
> 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?


> 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)


> 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.

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)

Hi

On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> wrote:
>
>
>
> 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.

The benefit is that QEMU would not have to maintain 10 backends and
all the audio mixing/resampling. The QEMU code would be simpler and
more maintainable overall. GStreamer has a clear pipeline design,
better suited (optimized code etc) and you can easily modify the
pipeline settings.

>
> >
> >> 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.

That's indeed a complicated subject and hard to test & measure. Adding
some testing to our audio infra should help identify this better. Not
sure when time permits though.

It seems to me that the current QEMU audio code is using the
virtual/system clock timer to pull the data at a regular pace, which
is not in sync with the actual audio sink clock. The GStreamer
pipeline, otoh, uses the audio sink clock. But there are other
emulated devices related issues (like hda not sending data when asked,
or later, it has to be pulled regularly etc). I need to study this in
more detail, this GStreamer implementation is a bit naive there.


>
> 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.

Yes, I think synchronization of audio/video playback for remoting is
another issue, if QEMU has the audio & video frames in sync which can
provide correct timestamps.

>
> 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.

(by default QEMU is still doing resampling & mixing, and adds extra buffering)

A GStreamer backend should not be incompatible with those use cases.

[..]
> 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.

I agree with the goal that we should leave most of the work to the
host, and not have to do audio mixing resampling ourself whenever
possible. Imho, GStreamer allows us to do that in less and cleaner
code.

-- 
Marc-André Lureau

On Tue, Dec 02, 2025 at 06:14:48PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> wrote:
> >
> >
> >
> > 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.
> 
> The benefit is that QEMU would not have to maintain 10 backends and
> all the audio mixing/resampling.

Well, for open-source projects it depends on the maintainers: if they
all shift their interrest/efforts toward a single GStreamer backend it
will be a win (many devs maintaining a single backend). If they don't,
we'd end-up with one backend maintained by one person.

> The QEMU code would be simpler and
> more maintainable overall. GStreamer has a clear pipeline design,
> better suited (optimized code etc) and you can easily modify the
> pipeline settings.
> 

I don't know if it would be more maintainable.  The idea is appealing,
but to my experience, fixing audio glitches, timing issues, unexpected
latency, subtle differences between OSes and alike have been painful
compared to fixing similar code that uses the native APIs.

My 2 cents.

On Tuesday, 2 December 2025 15:14:48 CET Marc-André Lureau wrote:
> On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> wrote:
> > 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.
> 
> The benefit is that QEMU would not have to maintain 10 backends and
> all the audio mixing/resampling. The QEMU code would be simpler and
> more maintainable overall. GStreamer has a clear pipeline design,
> better suited (optimized code etc) and you can easily modify the
> pipeline settings.

Nobody questions that it could reduce QEMU code. But it would move complexity 
to users by forcing them to add another layer. Many sound systems allow to be 
layered on top of other sound systems for a long time. But even only one 
additional layer can make it very challenging to find out why you end up with 
a certain undesired setup like unexpected sample rate or bit depth (wrong USB 
profile chosen of external audio device during USB enumeration? some default 
plugin or mixer element of a layer doing resampling?), high latency 
(additional buffers with higher size on some layer? where and why?) or even 
xruns.

/Christian

Hi,

On 2025-12-03 01:14, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> 
> wrote:
>> 
>> 
>> 
>> 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.
> 
> The benefit is that QEMU would not have to maintain 10 backends and
> all the audio mixing/resampling. The QEMU code would be simpler and
> more maintainable overall. GStreamer has a clear pipeline design,
> better suited (optimized code etc) and you can easily modify the
> pipeline settings.

Yes, I suppose I can see it from that point of view provided that the 
advanced features of GStreamer, such as user defined audio graphs, are 
never exposed to the user to configure. I can just imagine the false bug 
report nightmare this would induce (buggy plugins, etc).

> 
>> 
>> >
>> >> 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.
> 
> That's indeed a complicated subject and hard to test & measure. Adding
> some testing to our audio infra should help identify this better. Not
> sure when time permits though.
> 
> It seems to me that the current QEMU audio code is using the
> virtual/system clock timer to pull the data at a regular pace, which
> is not in sync with the actual audio sink clock. The GStreamer
> pipeline, otoh, uses the audio sink clock. But there are other
> emulated devices related issues (like hda not sending data when asked,
> or later, it has to be pulled regularly etc). I need to study this in
> more detail, this GStreamer implementation is a bit naive there.
> 

Yes, this is the primary issue here. I believe that solving this is more 
complicated then it appears however as headless systems that are using 
SPICE for audio wont have an audio clock to sync to.

> 
>> 
>> 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.
> 
> Yes, I think synchronization of audio/video playback for remoting is
> another issue, if QEMU has the audio & video frames in sync which can
> provide correct timestamps.

Note that I am referring to a SPICE client that only subscribes to the 
audio stream and not video, as is the case for Looking Glass as it uses 
an out of band mechanism to obtain the passthrough GPUs output. This is 
also occurs on the local host via a unix socket.

I do not think this aspect can be solved in QEMU, but rather must be 
solved in the SPICE client

See here if you're interested how we did this:
https://github.com/gnif/LookingGlass/blob/53bfb6547f2b7abd6c183192e13a57068c1677ea/client/src/audio.c

> 
>> 
>> 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.
> 
> (by default QEMU is still doing resampling & mixing, and adds extra 
> buffering)
> 
> A GStreamer backend should not be incompatible with those use cases.
> 

In that case, i'd suggest that if possible the GStreamber back end 
maintains the same port and node names it presents to Jack/PipeWire to 
make the transition from the other audio backends to GStreamer as 
painless as possible.

> [..]
>> 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.
> 
> I agree with the goal that we should leave most of the work to the
> host, and not have to do audio mixing resampling ourself whenever
> possible. Imho, GStreamer allows us to do that in less and cleaner
> code.

Great, as long as we don't let user's configure GStreamer's more 
advanced features its should be ok then.

Marc-André Lureau <marcandre.lureau@gmail.com> writes:

> Hi
>
> On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> wrote:
>>
>>
>>
>> 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.
>
> The benefit is that QEMU would not have to maintain 10 backends and

Twelve according to the QAPI schema.

> all the audio mixing/resampling. The QEMU code would be simpler and
> more maintainable overall.

This matters.

The question can't be whether some QEMU feature is useful to somebody
(it basically always is).  It must be whether it is worth its keep.

Maintaining code is not free.  Easy to forget when somebody else does
the actual work quietly and well.

I'm not qualified to judge either utility or maintenance of audio
drivers.  However, I trust our long-serving maintainers there.

>                            GStreamer has a clear pipeline design,
> better suited (optimized code etc) and you can easily modify the
> pipeline settings.

[...]

On 2025/12/02 23:52, Markus Armbruster wrote:
> Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> 
>> Hi
>>
>> On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> wrote:
>>>
>>>
>>>
>>> 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.
>>
>> The benefit is that QEMU would not have to maintain 10 backends and
> 
> Twelve according to the QAPI schema.
> 
>> all the audio mixing/resampling. The QEMU code would be simpler and
>> more maintainable overall.
> 
> This matters.
> 
> The question can't be whether some QEMU feature is useful to somebody
> (it basically always is).  It must be whether it is worth its keep.
> 
> Maintaining code is not free.  Easy to forget when somebody else does
> the actual work quietly and well.
> 
> I'm not qualified to judge either utility or maintenance of audio
> drivers.  However, I trust our long-serving maintainers there.

If someone touches the Core Audio backend after GStreamer gets in, my 
first question as a reviewer may be: why don't they use GStreamer instead?

GStreamer has mixing/resampling and Core Audio code that is:
- more optimized (e.g., SIMD resampling),
- better maintained, and
- has more features (GStreamer seems to support microphone/source while 
QEMU's coreaudio backend doesn't).

The reasons _not_ to use GStreamer I can come up with are:
- You don't have GStreamer installed. However I guess it will be 
automatically installed when doing "brew install qemu" once the 
GStreamer backend gets in.
- Bugs in GStreamer or the glue code between QEMU and GStreamer. But of 
course the code that connects QEMU's mixing/resampling has another set 
of bugs.

I think there is a good chance that nobody notices if the coreaudio 
backend breaks once GStreamer becomes the default.

Regards,
Akihiko Odaki

On Tue, Dec 2, 2025 at 9:15 AM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <geoff@hostfission.com> wrote:
> >
> >
> >
> > 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.
>
> The benefit is that QEMU would not have to maintain 10 backends and
> all the audio mixing/resampling. The QEMU code would be simpler and
> more maintainable overall. GStreamer has a clear pipeline design,
> better suited (optimized code etc) and you can easily modify the
> pipeline settings.
>
> >
> > >
> > >> 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.
>
> That's indeed a complicated subject and hard to test & measure. Adding
> some testing to our audio infra should help identify this better. Not
> sure when time permits though.
>
> It seems to me that the current QEMU audio code is using the
> virtual/system clock timer to pull the data at a regular pace, which
> is not in sync with the actual audio sink clock. The GStreamer
> pipeline, otoh, uses the audio sink clock. But there are other
> emulated devices related issues (like hda not sending data when asked,
> or later, it has to be pulled regularly etc). I need to study this in
> more detail, this GStreamer implementation is a bit naive there.
>
>
> >
> > 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.
>
> Yes, I think synchronization of audio/video playback for remoting is
> another issue, if QEMU has the audio & video frames in sync which can
> provide correct timestamps.
>
> >
> > 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.
>
> (by default QEMU is still doing resampling & mixing, and adds extra buffering)
>
> A GStreamer backend should not be incompatible with those use cases.
>

Have you tried to do this with VFIO and do semi-realtime audio (e.g.
AV work, gaming) with this backend?

In my experience, gapless and "crackle-less" semi-realtime audio is
unnecessarily difficult to do well with GStreamer right now.

Don't get me wrong, I *like* GStreamer, but I don't think it's as good
in this case as it is being positioned.

> [..]
> > 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.
>
> I agree with the goal that we should leave most of the work to the
> host, and not have to do audio mixing resampling ourself whenever
> possible. Imho, GStreamer allows us to do that in less and cleaner
> code.
>

GStreamer is a painful dependency on non-POSIX platforms, so I don't
think that our non-POSIX consumers would be happy about this.

Personally, I'd keep around at least the SDL Audio and PipeWire
backends too. That gives decent coverage and lets people avoid
problematic build and runtime dependencies.



--
真実はいつも一つ！/ Always, there's only one truth!

On Mon, 1 Dec 2025, Marc-André Lureau wrote:
> On Mon, Dec 1, 2025 at 5:03 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
>>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>>
>>> 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

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 <balaton@eik.bme.hu> wrote:
> > > On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
> > > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > > 
> > > > 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.

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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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 <balaton@eik.bme.hu> wrote:
>>>> On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
>>>>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>>>>
>>>>> 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

On Monday, 1 December 2025 14:02:41 CET BALATON Zoltan wrote:
> On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
[...]
> > 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
> 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
> 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
> as another audio backend but not as a replacement for QEMU's audio
> handling logic and backends.
> 
> Regards,
> BALATON Zoltan

I agree with Zoltan on this. GStreamer is nice as new backend, but I would 
also preserve the existing audio backends for the same reasons already 
described by Zoltan.

/Christian