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

Chris Robinson chris.kcat at gmail.com
Tue May 5 12:25:57 PDT 2009


On Tuesday 05 May 2009 10:09:10 am Ludwig Nussel wrote:
> 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.

PulseAudio only provides a new plugin type for ALSA, so normally you'd open 
"pulse" or "plug:pulse" to get PulseAudio through ALSA. You have to set up 
/etc/asound.conf or ~/.asoundrc to make it override ALSA's default device with 
the pulse plugin.. and apparently certain distros are doing just this. If it 
was left alone, then what would happen is:

App opens OpenAL
  OpenAL tries to open ALSA, and fails (no hardware, and no dmix).
  OpenAL tries to open OSS, and fails (no hardware, and no ALSA).
  OpenAL tries to open Pulse, and succeeds (PA's running).
App uses Pulse..

And everything's all fine and dandy. But because distros made the plugin be 
ALSA's default, opening ALSA succeeds, but behaves in a buggy manner. If the 
distros are so willing to jump in and make PulseAudio be ALSA's default via 
/etc/asound.conf, then they could do the same with OpenAL Soft via 
/etc/openal/alsoft.conf (though the fact that you'd need to do that speaks 
volumes about the readiness of PulseAudio becoming the default sound system 
for a distro).

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

I don't think it's possible, but trying to side-step the user's setup isn't 
something I think OpenAL Soft should do anyway. If the user has PulseAudio set 
to intercept ALSA's default device, and the user has OpenAL Soft set to use 
ALSA's default device, it's not my place to provide something different.


More information about the Openal-devel mailing list