[Openal-devel] openal-soft

[Daniel PEACOCK]

> 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* ;)).

You are quite right - we should make our examples work under Linux.  In
theory, the "Framework" source code just needs to be replaced with Linux
friendly implementations (we do exactly this for our Xbox360 SDK which
installs on top of the Windows installation).

> 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.

Yes that is (unfortunately) true.  There are some proprietary formulas
needed to convert the EAX 3/4/5 Reverb effect into "EAX Reverb" parameters
in EFX terminology.   This only matters if you have a set of existing EAX
3/4/5 reverb presets.  It is certainly not a requirement for using EFX.

In fact, it would be a good idea for us to ship some reverb presets in EFX
"EAX Reverb" "Reverb" format.  The OpenTK folks have done / will be doing
this.

> 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).

Some of the X-RAM functionality could (and perhaps should) have been
implemented with al[Get]Bufferi.  But some features, like finding the total
amount of X-RAM or the amount of available X-RAM would need separate
functions anyway.

> 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.

I'll get back to you on this.  I think re-distributing the efx.h file is
not problem ... but efx-creative.h would be (but you don't currently need
this anyway).

> > 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.

Exactly - any extension that includes functions should require the
application to call alGetProcAddress to the get the function addresses,
rather than directly exporting them.  This enables applications to work if
the extension is not available on a particular OpenAL implemenation.

Dan