Requirements, Conformance and Extensions

The specification has to guarantee a minimum number of resources. However, implementations are encouraged to compete on performance, available resources, and output quality.

NoteRFC: suggested requirements
 

These have been taken from earlier specs drafts, suggested by Creative: A minimum of sixteen (16) Sources per Context should always be available. The number and size of Buffers available is limited only by the amount of memory available and/or accessible by the implementation. The specification could also list requirements by the implementation: A minimum storage space of half a megabyte (512kB) should always be available.

NoteRFC: no requirements
 

I3DL1-like requirements might be so arbitrary that they are useless. The dangers here are cap bits, and a subtle aliasing of source and hardware buffers. AL implementations should implement as much quality and performance as possible for any given number of sources/ Application request resources when creating a context and can use Hints to indicate desired trade-offs.

There will be an OpenAL set of conformance tests available along with the open source sample implementation. Vendors and individuals are encouraged to specify and implement extensions to OpenAL in the same way OpenGL is extensible. Successful extensions will become part of the core specification as necessary and desirable. OpenAL implementations have to guarantee backwards compatibility and ABI compatibility for minor revisions.

The current sample implementation and documentation for OpenAL can be obtained from openal.org. OpenAL is also available from the the OpenAL CVS repository. For more information on how to get OpenAL from CVS also see Loki Software CVS.