| Message ID | 20190123080005.31078-5-kraxel@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | audio: rework driver probing. | expand |
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
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
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
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
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.
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
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.
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
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.
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
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.
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
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 > >
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
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 >
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.
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
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 > >
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
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
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 >
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"
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(-)