[PATCH] openal-soft: prefer pulseaudio backend

[Ludwig Nussel]

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.

[1] http://www.pulseaudio.org/wiki/PerfectSetup

Signed-off-by: Ludwig Nussel <ludwig.nussel@...>

---
 Alc/ALc.c        |    6 +++---
 Alc/pulseaudio.c |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Alc/ALc.c b/Alc/ALc.c
index 749e1d4..4e6ff88 100644
--- a/Alc/ALc.c
+++ b/Alc/ALc.c
@@ -53,6 +53,9 @@ static struct {
     void (*Init)(BackendFuncs*);
     BackendFuncs Funcs;
 } BackendList[] = {
+#ifdef HAVE_PULSEAUDIO
+    { "pulse", alc_pulse_init, EmptyFuncs },
+#endif
 #ifdef HAVE_ALSA
     { "alsa", alc_alsa_init, EmptyFuncs },
 #endif
@@ -71,9 +74,6 @@ static struct {
 #ifdef HAVE_PORTAUDIO
     { "port", alc_pa_init, EmptyFuncs },
 #endif
-#ifdef HAVE_PULSEAUDIO
-    { "pulse", alc_pulse_init, EmptyFuncs },
-#endif
 
     { "wave", alc_wave_init, EmptyFuncs },
 
diff --git a/Alc/pulseaudio.c b/Alc/pulseaudio.c
index 85a8276..6ba0255 100644
--- a/Alc/pulseaudio.c
+++ b/Alc/pulseaudio.c
@@ -250,7 +250,7 @@ static ALCboolean pulse_open(ALCdevice *device, ALCchar *device_name, ALCenum fo
 
     pa_context_set_state_callback(data->context, context_state_callback, data);
 
-    if(pa_context_connect(data->context, NULL, 0, NULL) < 0)
+    if(pa_context_connect(data->context, NULL, PA_CONTEXT_NOAUTOSPAWN, NULL) < 0)
     {
         AL_PRINT("Context did not connect: %s\n",
                  pa_strerror(pa_context_errno(data->context)));
--
1.6.2.1

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

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.

Hi.

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

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.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[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/

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

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.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Ludwig Nussel]

Chris Robinson wrote:
> [...]
> 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).

Well, fair enough. Would you mind including only the part that
prevents automatic starting of the pulseaudio daemon then? Without
that change pulseaudio would indeed be forced on everyone if the
preference order of the backends is changed.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\  
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Wednesday 06 May 2009 12:02:19 am Ludwig Nussel wrote:
> Well, fair enough. Would you mind including only the part that
> prevents automatic starting of the pulseaudio daemon then? Without
> that change pulseaudio would indeed be forced on everyone if the
> preference order of the backends is changed.

That's doable, yeah. I also should try to make it load dynamically like the
other backends, sometime.. and maybe clean up some of the non-error messages.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Ludwig Nussel]

Chris Robinson wrote:
> On Wednesday 06 May 2009 12:02:19 am Ludwig Nussel wrote:
> > Well, fair enough. Would you mind including only the part that
> > prevents automatic starting of the pulseaudio daemon then? Without
> > that change pulseaudio would indeed be forced on everyone if the
> > preference order of the backends is changed.
>
> That's doable, yeah.

Thanks!

> I also should try to make it load dynamically like the
> other backends, sometime..

Have you considered making the backends libraries themselves? It
should be much easier to dlopen a backend library rather than an
arbitrary external library. You basically only need to resolve the
init symbol then.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\  
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel