After the previous attempt by Nick Burns was more or less abandoned, I decided
to try making an acceptable version myself. This is the current result.
I used the original version Nick had and got rid a lot of the macro abuse. It
still uses macros to declare/define and load the functions, but it isn't
nearly as bad as it was. I know AJ isn't very thrilled with macro use, but I
believe the current method is a nice balance between flexibility and clarity.
Note that this IS NOT FINISHED. It should be good enough to work, however. The
main reason for this is to get some testing to make sure it works as expected
on other machines (especially OSX). The things I still need to work on are:
a) Skip building the DLL if OpenAL headers aren't found on the system
durring ./configure (any autotools experts want to help?)
b) Properly handle the autotools stuff (any autotools experts want to help?)
c) Fix up extension handling to use al[c]GetProcAddress instead of dlsym (for
the sake of being proper; I don't believe this would pose a problem
currently)
The OpenAL lib is dynamicly loaded, so the lib doesn't need to be present when
building. If the lib is not present when the DLL is loaded however, then the
DLL will fail to load. Because of this, it might be a good idea to include
OpenAL headers with Wine, so they will always be available to build the DLL
with (the headers are LGPL licensed, AFAIK). Won't have to worry about
skipping building or configure checking that way.
On my Linux machine, the OpenAL 1.1 SDK demos work*. I'm curious about how
they work for other people on other machines, and for other apps.
* Not quite true. EnumerateWin32.exe doesn't wait for a key press before
exiting, and OpenALDemo.exe won't wait for key presses when trying to pick a
test (it loops endlessly on the "main menu"). These problems are not related
to OpenAL. PlayStaticWin32.exe and PlayStreamWin32.exe both work perfectly,
and EnumerateWin32.exe does do what it's supposed to, with the exception of
the wait-for-key-before-exit problem.
Note that if you're using the Sample Implementation, you must get a recent (as
in today/yesterday) SVN checkout of it. It was missing a couple somewhat
obscure 1.1 functions I sent in a patch for and got applied.
After patching, you'll need to run autoconf (or autogen if you use that
script) to generate a new configure. Reconfigure, then rebuild Wine.
PS. I did get permission from Nick before posting this as I used
his "un-licensed" patch as a starting point. It's all okay with him.
PPS. I know not everyone likes the idea of this thunk, because the native
implementations aren't "up to par" with the Windows version that backends on
DSound. However, the only way they'll get better is with use (they've already
got several patches from me because of this thunk, with more pending, and
more in planning), and if worse comes to worse, you can use a DLL override to
use the Windows native OpenAL. Creative is planning on releasing hardware
OpenAL Linux drivers for some of their cards later this year, and this would
be the best way to take advantage of them.