On Tuesday 16 June 2009 8:44:36 pm Stefan Dösinger wrote:
There is such a DLL around - search the wine-devel and wine patches archives from it. Alexandre said he'd accept such a openal->openal thunk(but not an openal winmm driver). The problem why it is not included yet is that the latest state of the dll broke some games, the original developer ran out of time to work on it(I think he coded it during holiday from his job), and nobody since has continued working on it.
I actually have such a DLL thunk in my local tree, and it works perfectly using the newer openal libs (the OpenAL Soft 1.x libs, not the old OpenAL 0.0.x libs).
AFAIK, the main issue is that the al[c]GetProcAddress calls need to be fixed (currently they just call straight through to the native lib), and functions introduced by extensions need to be handled as well. On Linux this doesn't pose a problem, as OpenAL on Windows specifically uses the cdecl calling convention, and compilers on Linux default to cdecl. IIRC however, Alexendre said this won't work on OSX.
As well, I also have a DSound->OpenAL wrapper (like Alchemy) that works quite well. Games think they're getting hardware accelerated sound (since OpenAL doesn't really tell you if you've got hardware or not, I just fib..), and I get 5.1 surround sound output. It's not perfect, but the apps I tested all work great. Only thing is, it *needs* the DLL thunk to call to the native lib, otherwise the AL libs will try to use DSound for output, causing a circular dependency. And it currently won't work without an extension provided by OpenAL Soft, though I could work around that if I have to.
I'd also be interested in adding EAX support to it if OpenAL supports EFX, but I don't know what apps work with that, and I don't know how EAX in DSound works (or what the various levels of EAX have as a requirement).