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
