[Openal-devel] openal-soft

[Chris Robinson]

On Monday 11 February 2008 09:59:55 am Daniel PEACOCK wrote:
> 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.

Sounds good. :)

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

The total/free amount of X-RAM is queried with calls to alGetInteger (a 
standard AL function), using AL_EAX_RAM_SIZE/AL_EAX_RAM_FREE. Perhaps the 
X-RAM spec can be ammended to allow querying the buffer mode through 
al[Get]Bufferi as well as the two functions, with al[Get]Bufferi being the 
preferred method? eg.

alGetBufferi(uiBuffer, AL_XRAM_BUFFER_MODE, &val);
being equivilant to
eaxGetBufferMode(uiBuffer, &val);

and conversly:

alBufferi(uiBuffer, AL_XRAM_BUFFER_MODE, AL_STORAGE_AUTOMATIC);
being equivilant to
eaxSetBufferMode(1, &uiBuffer, AL_STORAGE_AUTOMATIC);

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

efx-creative.h is just the enum values (and min/max/default values as detailed 
in the EFX PDF) for the EAXReverb effect as used for EFX (the standard reverb 
and everything else being in efx.h). AFAIK, a compliant implementation needs 
to at least export all the effects' enums through alGetEnumValue (even if a 
given effect isn't implemented).. I'm just not sure if the min/max/default 
values are part of the spec and/or if I have to rewrite it all instead of 
using the already-existing headers in the SDK to get the values.