[Qemu-devel] [PATCH 0/4] audio: rework driver probing.

[Qemu-devel] [PATCH 0/4] audio: rework driver probing.

[Gerd Hoffmann]

Gerd Hoffmann (4):
  audio: use pkg-config
  audio: allow optional audio drivers.
  audio: use try-sdl and try-pa for openbsd
  [RfC] audio: probe audio drivers by default

 configure | 83 +++++++++++++++++++++++++++++++++++----------------------------
 1 file changed, 46 insertions(+), 37 deletions(-)

-- 
2.9.3

[Qemu-devel] [PATCH 1/4] audio: use pkg-config

[Gerd Hoffmann]

Use pkg-config to probe for alsa and pulseaudio.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 configure | 39 +++++++++++++--------------------------
 1 file changed, 13 insertions(+), 26 deletions(-)

diff --git a/configure b/configure
index 3eee3fcf70..bdb80f8cb1 100755
--- a/configure
+++ b/configure
@@ -3297,39 +3297,26 @@ fi
 ##########################################
 # Sound support libraries probe
 
-audio_drv_probe()
-{
-    drv=$1
-    hdr=$2
-    lib=$3
-    exp=$4
-    cfl=$5
-        cat > $TMPC << EOF
-#include <$hdr>
-int main(void) { $exp }
-EOF
-    if compile_prog "$cfl" "$lib" ; then
-        :
-    else
-        error_exit "$drv check failed" \
-            "Make sure to have the $drv libs and headers installed."
-    fi
-}
-
 audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/,/ /g')
 for drv in $audio_drv_list; do
     case $drv in
     alsa)
-    audio_drv_probe $drv alsa/asoundlib.h -lasound \
-        "return snd_pcm_close((snd_pcm_t *)0);"
-    alsa_libs="-lasound"
+    if $pkg_config alsa --exists; then
+        alsa_libs=$($pkg_config alsa --libs)
+    else
+        error_exit "$drv check failed" \
+            "Make sure to have the $drv libs and headers installed."
+    fi
     ;;
 
     pa)
-    audio_drv_probe $drv pulse/pulseaudio.h "-lpulse" \
-        "pa_context_set_source_output_volume(NULL, 0, NULL, NULL, NULL); return 0;"
-    pulse_libs="-lpulse"
-    audio_pt_int="yes"
+    if $pkg_config libpulse --exists; then
+        pulse_libs=$($pkg_config libpulse --libs)
+        audio_pt_int="yes"
+    else
+        error_exit "$drv check failed" \
+            "Make sure to have the $drv libs and headers installed."
+    fi
     ;;
 
     sdl)
-- 
2.9.3

[Qemu-devel] [PATCH 2/4] audio: allow optional audio drivers.

[Gerd Hoffmann]

For those audio drivers which can be probed (sdl, alsa, pulse) add a
try-$name variants.  Unlike the variants without try- prefix they will
not error out on probe failure, the driver will be dropped from the list
instead.  Mainly useful for the audio_drv_list default values.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 configure | 34 ++++++++++++++++++++++++++++------
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index bdb80f8cb1..6fef094f39 100755
--- a/configure
+++ b/configure
@@ -3300,22 +3300,36 @@ fi
 audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/,/ /g')
 for drv in $audio_drv_list; do
     case $drv in
-    alsa)
+    alsa | try-alsa)
     if $pkg_config alsa --exists; then
         alsa_libs=$($pkg_config alsa --libs)
+        if test "$drv" = "try-alsa"; then
+            audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/try-alsa/alsa/')
+        fi
     else
-        error_exit "$drv check failed" \
-            "Make sure to have the $drv libs and headers installed."
+        if test "$drv" = "try-alsa"; then
+            audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/try-alsa//')
+        else
+            error_exit "$drv check failed" \
+                "Make sure to have the $drv libs and headers installed."
+        fi
     fi
     ;;
 
-    pa)
+    pa | try-pa)
     if $pkg_config libpulse --exists; then
         pulse_libs=$($pkg_config libpulse --libs)
         audio_pt_int="yes"
+        if test "$drv" = "try-pa"; then
+            audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/try-pa/pa/')
+        fi
     else
-        error_exit "$drv check failed" \
-            "Make sure to have the $drv libs and headers installed."
+        if test "$drv" = "try-pa"; then
+            audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/try-pa//')
+        else
+            error_exit "$drv check failed" \
+                "Make sure to have the $drv libs and headers installed."
+        fi
     fi
     ;;
 
@@ -3325,6 +3339,14 @@ for drv in $audio_drv_list; do
     fi
     ;;
 
+    try-sdl)
+    if test "$sdl" = "no"; then
+        audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/try-sdl//')
+    else
+        audio_drv_list=$(echo "$audio_drv_list" | sed -e 's/try-sdl/sdl/')
+    fi
+    ;;
+
     coreaudio)
       coreaudio_libs="-framework CoreAudio"
     ;;
-- 
2.9.3

[Qemu-devel] [PATCH 3/4] audio: use try-sdl and try-pa for openbsd

[Gerd Hoffmann]

Fixes the openbsd build failure with SDL disabled.
Also enable pulseaudio support.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 6fef094f39..bbadd83fea 100755
--- a/configure
+++ b/configure
@@ -825,8 +825,8 @@ NetBSD)
 OpenBSD)
   bsd="yes"
   make="${MAKE-gmake}"
-  audio_drv_list="sdl"
-  audio_possible_drivers="sdl"
+  audio_drv_list="try-sdl try-pa"
+  audio_possible_drivers="sdl pa"
   HOST_VARIANT_DIR="openbsd"
   supported_os="yes"
 ;;
-- 
2.9.3

[Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Gerd Hoffmann]

Add the drivers listed in audio_possible_drivers to audio_drv_list,
using the try-* variants.  That way the probable drivers are compiled by
default if possible.

This is RfC because we might look at the ordering.  On linux we probably
want prefer alsa over oss.  Not sure about pulseaudio.  Most linux
distros use pulse by default on desktops.  On servers it'll probably not
be available.  Dunno how the situation looks like on the bsd family.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 configure | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/configure b/configure
index bbadd83fea..26e7668028 100755
--- a/configure
+++ b/configure
@@ -790,13 +790,13 @@ MINGW32*)
 ;;
 GNU/kFreeBSD)
   bsd="yes"
-  audio_drv_list="oss"
+  audio_drv_list="oss try-sdl try-pa"
   audio_possible_drivers="oss sdl pa"
 ;;
 FreeBSD)
   bsd="yes"
   make="${MAKE-gmake}"
-  audio_drv_list="oss"
+  audio_drv_list="oss try-sdl try-pa"
   audio_possible_drivers="oss sdl pa"
   # needed for kinfo_getvmmap(3) in libutil.h
   LIBS="-lutil $LIBS"
@@ -809,14 +809,14 @@ FreeBSD)
 DragonFly)
   bsd="yes"
   make="${MAKE-gmake}"
-  audio_drv_list="oss"
+  audio_drv_list="oss try-sdl try-pa"
   audio_possible_drivers="oss sdl pa"
   HOST_VARIANT_DIR="dragonfly"
 ;;
 NetBSD)
   bsd="yes"
   make="${MAKE-gmake}"
-  audio_drv_list="oss"
+  audio_drv_list="oss try-sdl"
   audio_possible_drivers="oss sdl"
   oss_lib="-lossaudio"
   HOST_VARIANT_DIR="netbsd"
@@ -841,7 +841,7 @@ Darwin)
     LDFLAGS="-arch x86_64 $LDFLAGS"
   fi
   cocoa="yes"
-  audio_drv_list="coreaudio"
+  audio_drv_list="coreaudio try-sdl"
   audio_possible_drivers="coreaudio sdl"
   LDFLAGS="-framework CoreFoundation -framework IOKit $LDFLAGS"
   libs_softmmu="-F/System/Library/Frameworks -framework Cocoa -framework IOKit $libs_softmmu"
@@ -857,7 +857,7 @@ SunOS)
   install="${INSTALL-ginstall}"
   smbd="${SMBD-/usr/sfw/sbin/smbd}"
   if test -f /usr/include/sys/soundcard.h ; then
-    audio_drv_list="oss"
+    audio_drv_list="oss try-sdl"
   fi
   audio_possible_drivers="oss sdl"
 # needed for CMSG_ macros in sys/socket.h
@@ -875,7 +875,7 @@ Haiku)
   LIBS="-lposix_error_mapper -lnetwork $LIBS"
 ;;
 Linux)
-  audio_drv_list="oss"
+  audio_drv_list="oss try-alsa try-sdl try-pa"
   audio_possible_drivers="oss alsa sdl pa"
   linux="yes"
   linux_user="yes"
-- 
2.9.3

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Thomas Huth]

On 2019-01-23 09:00, Gerd Hoffmann wrote:
> 
> This is RfC because we might look at the ordering.  On linux we probably
> want prefer alsa over oss.
Yes, please! I've run into the trap a couple of times already: OSS
headers were available, but these days the OSS compatibility kernel
modules are not loaded anymore by default. So you compile QEMU with OSS
support and then wonder why you do not get any audio output at all...

IMHO we should put OSS as last item in the list on Linux nowadays.

 Thomas

Re: [Qemu-devel] [PATCH 1/4] audio: use pkg-config

[Thomas Huth]

On 2019-01-23 09:00, Gerd Hoffmann wrote:
> Use pkg-config to probe for alsa and pulseaudio.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  configure | 39 +++++++++++++--------------------------
>  1 file changed, 13 insertions(+), 26 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Daniel P. Berrangé]

On Wed, Jan 23, 2019 at 09:27:48AM +0100, Thomas Huth wrote:
> On 2019-01-23 09:00, Gerd Hoffmann wrote:
> > 
> > This is RfC because we might look at the ordering.  On linux we probably
> > want prefer alsa over oss.
> Yes, please! I've run into the trap a couple of times already: OSS
> headers were available, but these days the OSS compatibility kernel
> modules are not loaded anymore by default. So you compile QEMU with OSS
> support and then wonder why you do not get any audio output at all...
> 
> IMHO we should put OSS as last item in the list on Linux nowadays.

Given our targetted platform list[1], are there even any platforms
where we would *not* have alsa, but still have OSS ?  If not, then
we could just drop the OSS driver entirely on the ground that it is
obsolete.

Regards,
Daniel

[1] https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms
-- 
|: 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 :|

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Thomas Huth]

On 2019-01-23 10:36, Daniel P. Berrangé wrote:
> On Wed, Jan 23, 2019 at 09:27:48AM +0100, Thomas Huth wrote:
>> On 2019-01-23 09:00, Gerd Hoffmann wrote:
>>>
>>> This is RfC because we might look at the ordering.  On linux we probably
>>> want prefer alsa over oss.
>> Yes, please! I've run into the trap a couple of times already: OSS
>> headers were available, but these days the OSS compatibility kernel
>> modules are not loaded anymore by default. So you compile QEMU with OSS
>> support and then wonder why you do not get any audio output at all...
>>
>> IMHO we should put OSS as last item in the list on Linux nowadays.
> 
> Given our targetted platform list[1], are there even any platforms
> where we would *not* have alsa, but still have OSS ?  If not, then
> we could just drop the OSS driver entirely on the ground that it is
> obsolete.

We likely could drop OSS on Linux, but it is still required on FreeBSD
and NetBSD, isn't it? So unless we can drop it there, too, we can also
simply keep it as last option in the list on Linux as well.

 Thomas

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Daniel P. Berrangé]

On Wed, Jan 23, 2019 at 10:50:18AM +0100, Thomas Huth wrote:
> On 2019-01-23 10:36, Daniel P. Berrangé wrote:
> > On Wed, Jan 23, 2019 at 09:27:48AM +0100, Thomas Huth wrote:
> >> On 2019-01-23 09:00, Gerd Hoffmann wrote:
> >>>
> >>> This is RfC because we might look at the ordering.  On linux we probably
> >>> want prefer alsa over oss.
> >> Yes, please! I've run into the trap a couple of times already: OSS
> >> headers were available, but these days the OSS compatibility kernel
> >> modules are not loaded anymore by default. So you compile QEMU with OSS
> >> support and then wonder why you do not get any audio output at all...
> >>
> >> IMHO we should put OSS as last item in the list on Linux nowadays.
> > 
> > Given our targetted platform list[1], are there even any platforms
> > where we would *not* have alsa, but still have OSS ?  If not, then
> > we could just drop the OSS driver entirely on the ground that it is
> > obsolete.
> 
> We likely could drop OSS on Linux, but it is still required on FreeBSD
> and NetBSD, isn't it? So unless we can drop it there, too, we can also
> simply keep it as last option in the list on Linux as well.

Ah ok, I didn't realize that BSD implemneted the OSS subsystem too.

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

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On 23.01.2019 10:50, Thomas Huth wrote:
> On 2019-01-23 10:36, Daniel P. Berrangé wrote:
>> On Wed, Jan 23, 2019 at 09:27:48AM +0100, Thomas Huth wrote:
>>> On 2019-01-23 09:00, Gerd Hoffmann wrote:
>>>>
>>>> This is RfC because we might look at the ordering.  On linux we probably
>>>> want prefer alsa over oss.
>>> Yes, please! I've run into the trap a couple of times already: OSS
>>> headers were available, but these days the OSS compatibility kernel
>>> modules are not loaded anymore by default. So you compile QEMU with OSS
>>> support and then wonder why you do not get any audio output at all...
>>>
>>> IMHO we should put OSS as last item in the list on Linux nowadays.
>>
>> Given our targetted platform list[1], are there even any platforms
>> where we would *not* have alsa, but still have OSS ?  If not, then
>> we could just drop the OSS driver entirely on the ground that it is
>> obsolete.
> 
> We likely could drop OSS on Linux, but it is still required on FreeBSD
> and NetBSD, isn't it? So unless we can drop it there, too, we can also
> simply keep it as last option in the list on Linux as well.
> 
>  Thomas
> 

NetBSD supports OSS compat without plans for abandoning it as it's a
good enough solution for desktop applications. Porting to our native
audio (SunOS) backend does not win much/anything as of now.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Gerd Hoffmann]

On Wed, Jan 23, 2019 at 09:27:48AM +0100, Thomas Huth wrote:
> On 2019-01-23 09:00, Gerd Hoffmann wrote:
> > 
> > This is RfC because we might look at the ordering.  On linux we probably
> > want prefer alsa over oss.
> Yes, please! I've run into the trap a couple of times already: OSS
> headers were available, but these days the OSS compatibility kernel
> modules are not loaded anymore by default. So you compile QEMU with OSS
> support and then wonder why you do not get any audio output at all...
> 
> IMHO we should put OSS as last item in the list on Linux nowadays.

Tweaked the pulseaudio driver to check whenever the damon pidfile is
present before trying to initialize.  With that in place we can move
pulse to be first in the list, without having pulse throwing error
messages when it can't connect the server.

So the linux ordering is this now:

	audio_drv_list="try-pa try-alsa try-sdl oss"

Requests / suggestions for other guests?

Probing pulseaudio first probably makes sense everywhere (when
available).  Most BSDs have both sdl and oss, which one should be
preferred here?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On 23.01.2019 11:12, Daniel P. Berrangé wrote:
> On Wed, Jan 23, 2019 at 10:50:18AM +0100, Thomas Huth wrote:
>> On 2019-01-23 10:36, Daniel P. Berrangé wrote:
>>> On Wed, Jan 23, 2019 at 09:27:48AM +0100, Thomas Huth wrote:
>>>> On 2019-01-23 09:00, Gerd Hoffmann wrote:
>>>>>
>>>>> This is RfC because we might look at the ordering.  On linux we probably
>>>>> want prefer alsa over oss.
>>>> Yes, please! I've run into the trap a couple of times already: OSS
>>>> headers were available, but these days the OSS compatibility kernel
>>>> modules are not loaded anymore by default. So you compile QEMU with OSS
>>>> support and then wonder why you do not get any audio output at all...
>>>>
>>>> IMHO we should put OSS as last item in the list on Linux nowadays.
>>>
>>> Given our targetted platform list[1], are there even any platforms
>>> where we would *not* have alsa, but still have OSS ?  If not, then
>>> we could just drop the OSS driver entirely on the ground that it is
>>> obsolete.
>>
>> We likely could drop OSS on Linux, but it is still required on FreeBSD
>> and NetBSD, isn't it? So unless we can drop it there, too, we can also
>> simply keep it as last option in the list on Linux as well.
> 
> Ah ok, I didn't realize that BSD implemneted the OSS subsystem too.
> 
> Regards,
> Daniel
> 

OSS is the portable UNIX audio backend. We could point some flaws in it,
but it's a good enough for portable UNIX applications. The question is
what UNIX-like desktop OS does not implement it or removed it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Peter Maydell]

On Wed, 23 Jan 2019 at 10:37, Kamil Rytarowski <n54@gmx.com> wrote:
> OSS is the portable UNIX audio backend. We could point some flaws in it,
> but it's a good enough for portable UNIX applications. The question is
> what UNIX-like desktop OS does not implement it or removed it.

If your desktop's native audio API is pulse, like Linux's often
is, then you want to use pulse directly, because the compat layers
are (or were last time I looked) not great, and typically add
in an extra thread and an extra layer of buffering, which means
more latency or more audio dropouts or both.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On 23.01.2019 11:59, Peter Maydell wrote:
> On Wed, 23 Jan 2019 at 10:37, Kamil Rytarowski <n54@gmx.com> wrote:
>> OSS is the portable UNIX audio backend. We could point some flaws in it,
>> but it's a good enough for portable UNIX applications. The question is
>> what UNIX-like desktop OS does not implement it or removed it.
> 
> If your desktop's native audio API is pulse, like Linux's often
> is, then you want to use pulse directly, because the compat layers
> are (or were last time I looked) not great, and typically add
> in an extra thread and an extra layer of buffering, which means
> more latency or more audio dropouts or both.
> 
> thanks
> -- PMM
> 

Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
mixer. So it adds nothing except additional intermediate layer.

For non-professional audio purposes OSS is good enough for such
applications.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Peter Maydell]

On Wed, 23 Jan 2019 at 11:09, Kamil Rytarowski <n54@gmx.com> wrote:
>
> On 23.01.2019 11:59, Peter Maydell wrote:
> > On Wed, 23 Jan 2019 at 10:37, Kamil Rytarowski <n54@gmx.com> wrote:
> >> OSS is the portable UNIX audio backend. We could point some flaws in it,
> >> but it's a good enough for portable UNIX applications. The question is
> >> what UNIX-like desktop OS does not implement it or removed it.
> >
> > If your desktop's native audio API is pulse, like Linux's often
> > is, then you want to use pulse directly, because the compat layers
> > are (or were last time I looked) not great, and typically add
> > in an extra thread and an extra layer of buffering, which means
> > more latency or more audio dropouts or both.

> Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
> mixer. So it adds nothing except additional intermediate layer.

Yes, exactly -- if your native API is OSS, we should be using that.
It's the compat layers that are problematic, so we can't just use
a single portable API on all platforms.

> For non-professional audio purposes OSS is good enough for such
> applications.

QEMU has to care about the buffering that compat layers add,
because guest programs tend to work on the assumption that they're
talking directly to the hardware and extra buffering trips them up.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On 23.01.2019 12:16, Peter Maydell wrote:
> On Wed, 23 Jan 2019 at 11:09, Kamil Rytarowski <n54@gmx.com> wrote:
>>
>> On 23.01.2019 11:59, Peter Maydell wrote:
>>> On Wed, 23 Jan 2019 at 10:37, Kamil Rytarowski <n54@gmx.com> wrote:
>>>> OSS is the portable UNIX audio backend. We could point some flaws in it,
>>>> but it's a good enough for portable UNIX applications. The question is
>>>> what UNIX-like desktop OS does not implement it or removed it.
>>>
>>> If your desktop's native audio API is pulse, like Linux's often
>>> is, then you want to use pulse directly, because the compat layers
>>> are (or were last time I looked) not great, and typically add
>>> in an extra thread and an extra layer of buffering, which means
>>> more latency or more audio dropouts or both.
> 
>> Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
>> mixer. So it adds nothing except additional intermediate layer.
> 
> Yes, exactly -- if your native API is OSS, we should be using that.
> It's the compat layers that are problematic, so we can't just use
> a single portable API on all platforms.
> 

OSS is +/- native for NetBSD, it uses a different selection of ioctl(2)s
and a thin compat layer in the kernel.

Maintaining a backend support for SunOS API (our current native audio)
does not win us at this point anything and it makes things worse as
there would be a need for more code to maintain. In my opinion it's
better to not add support for it in 3rd party software and look for
moving forward into sound subsystem on par with more modern solutions.
Until we will get there, the right thing is to use OSS.

>> For non-professional audio purposes OSS is good enough for such
>> applications.
> 
> QEMU has to care about the buffering that compat layers add,
> because guest programs tend to work on the assumption that they're
> talking directly to the hardware and extra buffering trips them up.
> 
> thanks
> -- PMM
> 

Correct, we don't want a stack of unwanted software like pulseaudio.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Gerd Hoffmann]

  Hi,

> Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
> mixer. So it adds nothing except additional intermediate layer.
> 
> For non-professional audio purposes OSS is good enough for such
> applications.

What happens if pulseaudio is running and using the sound device?  Can
qemu open and use the device in parallel?  "in-kernel mixer" sounds like
this is works and the kernel mixes the streams from all applications
before sending it to the sound device.  Or will qemu get a -EBUSY?

If parallel usage works we can default to oss I think.  Otherwise we
should try pulse first, and in case it is not available (daemon not
running) try oss next.

What about sdl?  Prefer oss over sdl I guess?  Or the other way around?

What is the native sound interface for openbsd btw?  oss doesn't
compile (missing sys/soundcard.h header).

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

On 23.01.2019 13:20, Gerd Hoffmann wrote:
>   Hi,
> 
>> Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
>> mixer. So it adds nothing except additional intermediate layer.
>>
>> For non-professional audio purposes OSS is good enough for such
>> applications.
> 
> What happens if pulseaudio is running and using the sound device?  Can
> qemu open and use the device in parallel?  "in-kernel mixer" sounds like
> this is works and the kernel mixes the streams from all applications
> before sending it to the sound device.  Or will qemu get a -EBUSY?

Multiple applications can use the OSS/native kernel API device nodes
concurrently and the in-kernel mixer will take care of mixing.

This approach has some cons, but it's practical in the current state of
affairs.

As far as I'm aware FreeBSD uses a similar approach.

> 
> If parallel usage works we can default to oss I think.  Otherwise we
> should try pulse first, and in case it is not available (daemon not
> running) try oss next.
> 
> What about sdl?  Prefer oss over sdl I guess?  Or the other way around?
> 
> What is the native sound interface for openbsd btw?  oss doesn't
> compile (missing sys/soundcard.h header).
> 

OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
enforced for all [well integrated] audio applications.

SDL is an optional intermediate layer kept for practical/compatibility
purposes, but all software shall use sndio natively.

> cheers,
>   Gerd
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Gerd Hoffmann]

  Hi,

> > What is the native sound interface for openbsd btw?  oss doesn't
> > compile (missing sys/soundcard.h header).
> 
> OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
> enforced for all [well integrated] audio applications.

Hmm.  Yet another audio daemon.  /me wonders why people keep reinventing
the wheel.

> SDL is an optional intermediate layer kept for practical/compatibility
> purposes, but all software shall use sndio natively.

Is pulseaudio supported?  The package is at least in the package
collection.  If so, then we can choose between pulse and sdl as middle
man, due to the lack of a sndio backend.  Which of the two should be
preferred?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

On 23.01.2019 14:59, Gerd Hoffmann wrote:
>   Hi,
> 
>>> What is the native sound interface for openbsd btw?  oss doesn't
>>> compile (missing sys/soundcard.h header).
>>
>> OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
>> enforced for all [well integrated] audio applications.
> 
> Hmm.  Yet another audio daemon.  /me wonders why people keep reinventing
> the wheel.
> 

This is rather more complex. OpenBSD struggles to remove all !sndio
solutions, with a good record track of applications switched to it.

There is also support for other BSDs and Linux in sndio so it is a
viable piece of software to be adopted more widely.

>> SDL is an optional intermediate layer kept for practical/compatibility
>> purposes, but all software shall use sndio natively.
> 
> Is pulseaudio supported?  The package is at least in the package
> collection.  If so, then we can choose between pulse and sdl as middle
> man, due to the lack of a sndio backend.  Which of the two should be
> preferred?
> 

I cannot speak definitely for OpenBSD, as I've never installed it
myself. I guess that pulseaudio is more unwanted and not expected at all
as a supported backed.

> cheers,
>   Gerd
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Brad Smith]

On 1/23/2019 8:59 AM, Gerd Hoffmann wrote:

>    Hi,
>
>>> What is the native sound interface for openbsd btw?  oss doesn't
>>> compile (missing sys/soundcard.h header).
>> OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
>> enforced for all [well integrated] audio applications.
> Hmm.  Yet another audio daemon.  /me wonders why people keep reinventing
> the wheel.

The wheel wouldn't be reinvented if there were viable options. There 
were none.

>> SDL is an optional intermediate layer kept for practical/compatibility
>> purposes, but all software shall use sndio natively.
> Is pulseaudio supported?  The package is at least in the package
> collection.  If so, then we can choose between pulse and sdl as middle
> man, due to the lack of a sndio backend.  Which of the two should be
> preferred?

Very much SDL. PulseAudio is avoided like the plague.

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Gerd Hoffmann]

On Wed, Jan 23, 2019 at 09:54:13AM -0500, Brad Smith wrote:
> On 1/23/2019 8:59 AM, Gerd Hoffmann wrote:
> 
> >    Hi,
> > 
> > > > What is the native sound interface for openbsd btw?  oss doesn't
> > > > compile (missing sys/soundcard.h header).
> > > OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
> > > enforced for all [well integrated] audio applications.
> > Hmm.  Yet another audio daemon.  /me wonders why people keep reinventing
> > the wheel.
> 
> The wheel wouldn't be reinvented if there were viable options. There were
> none.

https://xkcd.com/927/

> > > SDL is an optional intermediate layer kept for practical/compatibility
> > > purposes, but all software shall use sndio natively.
> > Is pulseaudio supported?  The package is at least in the package
> > collection.  If so, then we can choose between pulse and sdl as middle
> > man, due to the lack of a sndio backend.  Which of the two should be
> > preferred?
> 
> Very much SDL. PulseAudio is avoided like the plague.

Ok, so be it.  Lets go with SDL only for openbsd.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On 23.01.2019 16:12, Gerd Hoffmann wrote:
> On Wed, Jan 23, 2019 at 09:54:13AM -0500, Brad Smith wrote:
>> On 1/23/2019 8:59 AM, Gerd Hoffmann wrote:
>>
>>>    Hi,
>>>
>>>>> What is the native sound interface for openbsd btw?  oss doesn't
>>>>> compile (missing sys/soundcard.h header).
>>>> OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
>>>> enforced for all [well integrated] audio applications.
>>> Hmm.  Yet another audio daemon.  /me wonders why people keep reinventing
>>> the wheel.
>>
>> The wheel wouldn't be reinvented if there were viable options. There were
>> none.
> 
> https://xkcd.com/927/
> 

There is a different context on BSD than on Linux. We can choose one
solution and switch to it literally all the software keeping everything
in a single ports tree.

This is what happened on OpenBSD.

The result is that almost everything uses sndio, and pulseaudio is far
behind in adoption in any distro.

>>>> SDL is an optional intermediate layer kept for practical/compatibility
>>>> purposes, but all software shall use sndio natively.
>>> Is pulseaudio supported?  The package is at least in the package
>>> collection.  If so, then we can choose between pulse and sdl as middle
>>> man, due to the lack of a sndio backend.  Which of the two should be
>>> preferred?
>>
>> Very much SDL. PulseAudio is avoided like the plague.
> 
> Ok, so be it.  Lets go with SDL only for openbsd.
> 

Please skip pulseaudio for NetBSD and FreeBSD too. Even if it works (and
I've contributed NetBSD patches), it's used as a last resort solution.

> cheers,
>   Gerd
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Gerd Hoffmann]

  Hi,

> > https://xkcd.com/927/
> 
> There is a different context on BSD than on Linux. We can choose one
> solution and switch to it literally all the software keeping everything
> in a single ports tree.
> 
> This is what happened on OpenBSD.
> 
> The result is that almost everything uses sndio, and pulseaudio is far
> behind in adoption in any distro.

I'm not going to join the sndio vs. pulse discussion.

But from a maintenance point of view it sucks big time to have a bunch
of ways to play sound, and everybody uses a different one so you have to
maintain a backend for each of those methods.

Maybe we should outsource that problem.  Write a gstreamer backend, then
delete oss/alsa/sdl/pulse/whatever backends and let gstreamer handle
that mess ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Thomas Huth]

On 2019-01-24 07:38, Gerd Hoffmann wrote:
[...]
> I'm not going to join the sndio vs. pulse discussion.
> 
> But from a maintenance point of view it sucks big time to have a bunch
> of ways to play sound, and everybody uses a different one so you have to
> maintain a backend for each of those methods.
> 
> Maybe we should outsource that problem.  Write a gstreamer backend, then
> delete oss/alsa/sdl/pulse/whatever backends and let gstreamer handle
> that mess ...

Well, before writing a gstreamer backend, you could also say that we
only support SDL in QEMU, since SDL is also a wrapper around all the
other possible sound backends...

 Thomas

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On 24.01.2019 07:38, Gerd Hoffmann wrote:
>   Hi,
> 
>>> https://xkcd.com/927/
>>
>> There is a different context on BSD than on Linux. We can choose one
>> solution and switch to it literally all the software keeping everything
>> in a single ports tree.
>>
>> This is what happened on OpenBSD.
>>
>> The result is that almost everything uses sndio, and pulseaudio is far
>> behind in adoption in any distro.
> 
> I'm not going to join the sndio vs. pulse discussion.
> 
> But from a maintenance point of view it sucks big time to have a bunch
> of ways to play sound, and everybody uses a different one so you have to
> maintain a backend for each of those methods.
> 
> Maybe we should outsource that problem.  Write a gstreamer backend, then
> delete oss/alsa/sdl/pulse/whatever backends and let gstreamer handle
> that mess ...
> 

Just please leave it to OS maintainers.

There is no fragmentation in BSD distributions so sndio isn't different
to native sound system on Darwin or Windows and I see no complains that
Windows does not adapt PulseAudio. (Probably the only practical
difference is BSD being open-source.)

> cheers,
>   Gerd
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 850 bytes --]