On Wednesday, February 15, 2023 4:59:47 PM CET Daniel P. Berrangé wrote: > On Wed, Feb 15, 2023 at 05:18:50PM +0400, 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..) > > Even if we take this patch, and don't have a gstreamer impl, > it feels like we've scope for cutting down the backends. > > The 'oss' driver for example ? On Linux that's long obsolete, > with alsa or one of the higher level APIs available. OSS was > also use on freebsd, but IIUC, sndio is better choice there > now too ? Deprecate (and later remove) 'oss' now ?
There is indeed little reason to still use OSS nowadays IMO. At least marking OSS as deprecated would not hurt. > The 'sdl' driver is setup in meson.build as our lowest priority > impl, we'll pick any other driver ahead of sdl. Is there any > compelling reason why we must give users the option of 'sdl' > for audio when we have soo many other choices available ? > Even if using SDL for graphics, it seems like we can use any > other backend for audio. Deprecate (and later remove) 'sdl' > for audio ? > > IIUC, pipewire is positioned to replace pulseaudio. So if we > take a pipewire backend, once pipewire is available in enough > distros we could deprecate the pulseaudio backend and eventually > remove it. Maybe the same applies for 'jack' ? AFAIK Pipewire is Linux only, whereas PulseAudio and JACK are available for Windows and macOS, too. And in it's current version (provided QEMU Pipewire patch), I don't see it as a full replacement for the JACK driver yet. > IOW, could we get to > > - Windows: dsound > - MacOS: coreaudio > - (Open|Net|Free)BSD: sndio > - Linux: alsa/pipewire > > ? > > With regards, > Daniel >
