OpenAL and DSound (was Re: Fate of PulseAudio in WINE)
chris.kcat at gmail.com
Tue Jun 16 23:31:54 CDT 2009
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
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).
More information about the wine-devel