[Openal-devel] [PATCH] openal-soft: prefer pulseaudio backend

[Ludwig Nussel]

Chris Robinson wrote:
> On Tuesday 05 May 2009 3:02:32 am Ludwig Nussel wrote:
> > While toying with pulseaudio I noticed openal-soft now gained native
> > support in recent git versions. openal-soft however uses alsa by
> > default which doesn't seem to make sense. On "perfect"[1] pulseaudio
> > installations an alsa plugins reroutes sound to pulseaudio.
> > Therefore openal-soft would always use that emulation mode instead
> > of native support. So preferring pulseaudio by default but not
> > causing the pulseaudio daemon to start automatically is the better
> > choice IMHO.
> 
> Thanks for the patch, but I'm not sure it's a good idea. OpenAL Soft uses 
> ALSA/OSS/AudioIO/DSound by default since these are the native sound APIs 
> provided by the target systems.
> 
> Ideally, OpenAL should not be running through a sound server like PulseAudio 
> since it's designed for real-time use and handles all its own mixing for the 
> device.. using a hardware voice would be best, while dmix would be fine for 
> non-hw-mixing cards when you need other apps to play sound. A sound server 
> just adds more overhead (OpenAL Soft does software mixing, then sends to 
> PulseAudio which does software mixing, then sends to the sound API which may 
> do software mixing..).

AFAIK pulseaudio opens the hardware device, therefore dmix doesn't
work.

> Normally I'd just let Pulse's ALSA plugin do the work for people that really 
> want to use it, since that's what it's there for. I added a PulseAudio backend 
> mainly because certain bugs with its ALSA plugin don't seem to be getting 
> fixed, and because of certain Linux distros' decisions to force it by default. 
> Without the PulseAudio backend, OpenAL Soft had a difficult time working for 
> those users. That, and because I don't use and can't properly test it, Pulse 
> isn't the recommended backend to use.

Well, I can't disagree and I don't intend to advocate pulseaudio.
After all I'm not using it either. However looking at the situation
from a distro packager's point of view probing for pulseaudio first
seems to make sense. I can't expect users to edit their ~/.alsoftrc
when using GNOME. Defaulting to the alsa backend causes trouble as
you said.

Is there a way for openal to detect whether pulseaudio intercepts
the alsa device? In this case openal could either try to open the
hardware device as well (succeeds for cards with hw mixing I guess)
or use the pulseaudio backend directly.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/