Re: [PATCH] audio/pwaudio.c: Add Pipewire audio backend for QEMU

["Daniel P. Berrangé" <berrange@redhat.com>]

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

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

IOW, could we get to

 - Windows: dsound
 - MacOS: coreaudio
 - (Open|Net|Free)BSD: sndio
 - Linux: alsa/pipewire

?

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