On 2025/12/02 23:52, Markus Armbruster wrote:
Marc-André Lureau <[email protected]> writes:
Hi
On Tue, Dec 2, 2025 at 5:26 PM Geoffrey McRae <[email protected]> wrote:
On 2025-12-02 23:44, Marc-André Lureau wrote:
Hi Geoffrey
On Tue, Dec 2, 2025 at 4:31 PM Geoffrey McRae
<[email protected]> 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
