> > My point is that pipewire has ALSA plugin (and also pulseaudio compat > library etc). So why add another back in QEMU? > Good question. Well the pulseaudio compatibility layer adds to the runtime overhead and dependency, dropping the usage of pw-pulse daemon as a runtime dependency would reduce footprint. For ALSA, it's a native layer and you do not want clients talking to ALSA directly if they need to share resources with other processes.
Regards, Dorinda. On Wed, Feb 15, 2023 at 3:11 PM Marc-André Lureau < marcandre.lur...@gmail.com> wrote: > Hi > > On Wed, Feb 15, 2023 at 6:09 PM Christian Schoenebeck > <qemu_...@crudebyte.com> wrote: > > > > On Wednesday, February 15, 2023 2:18:50 PM CET Marc-André Lureau wrote: > > > Hi > > > > > > On Wed, Feb 15, 2023 at 12:51 PM Dorinda Bassey <dbas...@redhat.com> > wrote: > > > > > > > > This commit adds a new audiodev backend to allow QEMU to use > Pipewire as > > both an audio sink and source. This backend is available on most systems. > > > > > > > > > > Hmm, I would rather have less audio (and ui) backends in QEMU. (for > > > audio, if I could introduce and keep only one, that would be > > > GStreamer: to remove the others..) > > > > > > What is the main advantage compared to using the ALSA backend? (I > > > assume pipewire depends on ALSA anyway on Linux) > > > > I think it does make sense to add Pipewire. Apparently it gains > popularity. > > My point is that pipewire has ALSA plugin (and also pulseaudio compat > library etc). So why add another back in QEMU? > > > The main advantage of Pipewire is its interoperability: It allows you to > > connect apps with each other that only support a specific audio system. > Say > > one app that only supports JACK, another app that only supports > PulseAudio, > > another that only supports ALSA and so on. So it tries to provide a > universal > > plug on a system for all. > > > > Best regards, > > Christian Schoenebeck > > > > > > > -- > Marc-André Lureau > >
