[Openal-devel] OpenAL Driver Selection

[Daniel PEACOCK]

Hi Richard,

> Anyway, I am finding one major problem area - I'm finding that I
> have to do quite a bit of "hacking" to make games use my driver. For
> instance, depending on the game, I've found myself having to:
> Remove other *_oal.dll files from the windows/system32 directory.
> Put them back.
> Remove *_oal.dll or other DLLs from local game directories as some
> seem to use a local copy of OpenAL.
> Drop my own DLL (gas_oal.dll) into game directories as well as
> windows/system32.
> Have my driver report itself as "Generic Software" rather than its
> normal label ("GOAL").
>
> All of these things make me nervous. Am I doing something wrong?

Due to all sorts of reasons, some game developers ...

a) Don't want to use the OpenAL Installer - and therefore need local DLLs
b) Don't want to support particular devices
c) Require XXX number of voices
d) Require EAX X support
e) Don't want to display the list of available devices to the user
f) Want to simplify the options available to a user (e.g Audio Hardware On
/ Off)

We (Creative) would like everyone to use the OpenAL Installer and use the
device enumeration extension to give the user the choice of any OpenAL
device on the system, but we understand that there can be reasons why this
is not possible or desirable.  Our SDK includes a document called "OpenAL
Deployment Guide" with these recommendations - but maybe that is a bit
hidden away.

For testing *only* ... I would recommend renaming your OpenAL
implementation from goal.dll to OpenAL32.dll and always putting it in the
same folder as the game executable.  You should also make your
alcOpenDevice accept *any* input string.  This should enable most games to
use your OpenAL device (unless they require a certain feature).

> My instinct is that the right thing to do is to update the router
> DLL so that it's configurable by the user and to tighten up the
> documentation to encourage games designers to use the central OpenAL
> install and the default implementation (unless they have a good
> reason not to). We could put a nice glossy screen into Control Panel
> or suchlike which could examine the OpenAL implementations available
> on the machine, enable/disable, select the default and perhaps
> provide few test buttons. I think this would suit everyone - folk
> buying expensive kit can switch between Generic Software and their
> new shiny X-Fi or whatever and hear the difference. They can also
> show off to their friends, which helps out the card manufacturers.
> The user can also test out and switch off a driver that's causing
> problems e.g. by claiming to provide facilities that aren't actually
> there (no names ;-). Game developers get to see/hear what's actually
> "going on" and test out multiple drivers easily, plus tell the user
> not to use a particular driver if there are compatibility issues.
> And it would greatly increase the visibility and immediacy of OpenAL
> to ordinary users!
> What do folk reckon? I guess the biggest problem with this is that
> it's a reasonably chunky slice of work...

We've talked about this idea at Creative.  It could be nice to have an
OpenAL configuration panel that stores setting in the registry which are
used by the OpenAL32.dll router component to control device selection.

I don't think this could solve all the problems though ... e.g. if an
application has a local openal32.dll then the new 'configurable router'
would never be loaded anyway.  There may be problems with games that need
particular feature-sets too.

Dan