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.
