| OpenAL Specification and Reference | ||
|---|---|---|
| <<< Previous | Extensions | Next >>> |
The extensions described have at one point been in use for experimental purposes, proof of concept, or short term needs. They are preserved for backwards compatibility. Use is not recommended, avialability not guaranteed. Most of these will be officially dropped by the time API revision 2.0 is released.
AL currently does not provide a separate processing chain for multichannel data. To handle stereo samples, the following alternative entry point to BufferData has been defined.
void BufferWriteData( uint bufferName, enum format, void *; data , sizei size , uint frequency, enum internalFormat);
Experimental implementation to append data to an existing buffer. Obsoleted by Buffer Queueing. TBA.
![]() | Annotation (GenStreamingBuffers): |
|---|---|
It is possible that a consistent implementation of this extension will require distinguishing streaming from regular buffers at creation time, instead of making this distinction implied by the use of BufferData vs. BufferAppendData. |
Experimental implementation to allow the application to specify a decoding callback for compression formats and codecs not supported by AL. This is supposed to be used if full uncompression by the application is prohibited by memory footprint, but streaming (by queueing) is not desired as the compressed data can be kept in memory in its entirety.
If mixing can be done from the compressed data directly, several sources can use the sample without having to be synchronized. For compression formats not supported by AL, however, partial decompression has to be done by the application. This extension allows for the implementation to "pull" data, using apllication provided decompression code.
The use of this callback by the AL implementation makes sense only if late decompression (incremerntal, on demand, as needed for mixing) is done, as full early compression (ahead-of-time) inside the implementation would exact a similar memory footprint.
TBA.
This extension forces execution of third party code during (possibly threaded) driver operation, and might also require state management with global variables for decoder state, which raises issues of thread safety and use for multiple buffers. This extension should be obsolete as soon as AL supports a reasonable set of state of the art compression and encoding schemes.
To support infinite looping, a boolean LOOP was introduced. With the introduction of buffer queueing and the request for support for a limited number of repetitions, this mechanism was redundant. This extension is not supported for buffer queue operations, attempts to use it will cause an ILLEGAL_OPERATION error. For backwards compatibility it is supported as the equivalent to
Source( sName, PLAY_COUNT, MAX_INTEGER )
Table 1. Source LOOP_LOKI Attribute
| Name | Signature | Values | Default |
|---|---|---|---|
| LOOP_LOKI | b | TRUE FALSE | FALSE |
The following has been obsoleted by explicit Source State query. hack.
Table 2. Buffer BYTE Offset attribute
| Name | Signature | Values | Default |
|---|---|---|---|
| BYTE_LOKI | ui | n/a | n/a |
| <<< Previous | Home | Next >>> |
| Other Extension | Up | Loop Point Extension |