[Openal-devel] openal-soft

[Chris Robinson]

On Friday 08 February 2008 03:55:54 pm Lukasz Pawelczyk wrote:
> Lukasz Pawelczyk wrote:
> > I'll try to give EFX10Show a shot later today.
>
> Hmm, thats kinda hard to do.
>
> 1. There are no sources for it in SDK, only binary.
> 2. The rest of EFX examples seems to be rather hard to compile under
> Linux.

Actually I'm not sure you can compile it under Linux. IIRC, Creative was 
thinking of porting some of their stuff to work on Linux, but I don't know if 
they have, or if that includes the SDK stuff (would be nice if it did 
*hint*hint* ;)).

If you have Windows, you can just put OpenAL Soft's dll into the sample's 
win32 bin directory and run them. Personally, I run them under Wine with an 
openal32 dll thunk.

> The Framework is written for windows. I tried changing 
> headers/types to Linux ones, but I have no idea what are ks.h and
> ksmedia.h (needed by CWaves which is needed by Framework). Besides
> windows OpenAL seems to have much more header files which are used there
> (efx.h, efx-creative.h, efx-util.h and xram.h which is probably X-Fi
> specific).

ks.h and ksmedia.h are Windows headers that define some guids for some media 
types and other stuff, which I guess the wave loader uses. efx-utils.h is for 
functions that convert predefined EAX reverb settings to EFX (using the 
EAXReverb effect, unfortunately enough; OpenAL Soft only does the standard 
reverb effect currently).. the actual functions seem to be in a pre-compiled 
lib.

The last three are for exensions. The stuff for XRAM would be easy enough to 
include in alext.h (it's just two typedefs and five enums), except OpenAL 
Soft has no support or use for it being as the extension is used for sound 
hardware memory. (though on the subject, I'd mention that I find it odd that 
it uses new functions instead of a buffer attribute with alBufferi and 
alGetBufferi as one would expect).

efx-creative.h is for the eaxreverb settings, which isn't too useful without 
efx.h, which is the main EFX stuff. Now, by all rights, the stuff defined for 
the EFX extension should be in alext.h. However, I'm not too comfortable with 
just copying the whole of both files (efx.h and efx-creative.h) verbatim or 
packaging them with OpenAL Soft, nor am I sure if it's all part of the spec 
(some of the macros aren't mentioned in the pdf).

If I can get an okay from Creative for using the headers under the LGPL, 
though, that'd be really great.

> Besides that while fighting with it I found that (I think) those
> examples are using internal OpenAL calls.
>
> example (after including al.h, alc.h and alext.h, but no Framework.h):
> EFXFilter.cpp:36: error: 'alGenFilters' was not declared in this scope
> EFXFilter.cpp:40: error: 'alIsFilter' was not declared in this scope

Framework.h declares those as function pointers (as they should be) which are 
then loaded by ALFWIsEFXSupported in Framework.cpp.