[Openal-devel] OpenAL Driver Selection

[Richard Furse]

> -----Original Message-----
> From: openal-devel-bounces at opensource.creative.com
> [mailto:openal-devel-bounces at opensource.creative.com] On Behalf Of 
> Chris Robinson
> Sent: 13 June 2008 01:08
> To: openal-devel at opensource.creative.com
> Subject: Re: [Openal-devel] OpenAL Driver Selection
[...]
> I could've sworn some games (such as
> those based on the
> Doom3 engine) let you select the device, even if manually, but I can't 
> find the config variable for it..

I never did get Doom3 working with my OpenAL driver, and now 
I can't find the CD! Are you sure it works? If so, I'll 
persist in my search... I like Enemy Territory too - do you 
know if that can be persuaded?

> I agree it would be nice though, if more apps included an option for 
> selecting a specific device.
> 
> > 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 like this idea. Something I wanted to do for OpenAL Soft is to make 
> a GUI app (using Qt4) to let users specify what default output 
> parameters and devices to use. I've just never got around to it 
> because I don't know anything about coding GUI apps. But having a 
> Windows equivilant of that would be nice. Say, a control panel applet 
> that lets you enable/disable specific drivers (*oal.dll files) and set 
> their priorities, along with a tab for each driver that exports a 
> configuration interface from the DLL to configure itself. Drivers that 
> don't export such an interface just wouldn't get its own configuration 
> tab, but could still be enabled/disabled and prioritized.

Yep. This would be ideal. How would the parameters be 
exposed? Strong-typed properties seem the easiest immediate 
suggestion... Maybe there's a way in Windows already? We 
could embed GUI code directly in the DLL, but then there are 
all sorts of compatibility gotchas down the line. Another 
option is to provide a link to a DLL-specific config binary 
(ASIO does things this way I think). Perhaps the ideal might 
be a hybrid between this and strong-typed config.

We could code this up as an OpenAL extension through the 
normal mechanism. Hmmm...

Best wishes,

--Richard