Compatibility Extensions

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.

Loki Buffer InternalFormat Extension

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

Valid formats for internalFormat are FORMAT_MONO8, FORMAT_MONO16, FORMAT_STEREO8, and FORMAT_STEREO16.

Loki BufferAppendData Extension

Experimental implementation to append data to an existing buffer. Obsoleted by Buffer Queueing. TBA.

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

NoteRFC: alBufferAppendData
 

Specify data to be filled into a streaming buffer. This takes the current position at the time of the call, and returns the number of samples written. ALsizei ALAPIENTRY alBufferAppendData( ALuint buffer, ALenum format, ALvoid* data, ALsizei size, ALuint freq );

NoteRFC: GenStreamingBuffers
 

Currently there is a function call on the Linux side, alGenStreamingBuffers(), which generates a Buffer intended for streaming. The intent of this function was the provide a clear creation point for streaming buffers, rather than the previous behaviour of a Buffer "magically" becoming streaming Buffer the first time BufferAppendData() was called on it. However, it's hard to believe this anomaly in the API can be any better. What about DelStreamingBuffers()? IsStreamingBuffer()?

The design problem here is that we handle qualitatively different objects using the same API. Streaming and non-streaming buffers are fundamentally different. If we create an API that makes it easy to mistake one for the other, or worse, if we decide to quietly convert one type of object into another in some cases, we create a plethora of error cases for the implementation and the app coder to catch. Separating the Factory methods for the objects allows us to omit an specialization API that will accidentally be called more than once, and saves us handling different stages of "initialization state". AL should not have any notion of "partially initialized" or "incomplete" objects: misery and despair lie down that road. If necessary the entire API should be duplicated (after all, nobody handles 1D, 2D, and 3D textures using the same GL API hooks), but as the AL implementation has the ability to distinguish streaming and non-streamin buffers internally there might not be a need. Unless a concrete alternative is proposed to resolve the "anomaly" it will be the preferred method to avoid an API that is leaner at the expense of being more error-prone.

Loki Decoding Callback Extension

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.

Loki Infinite Loop Extension

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 ) 
       

For the query LOOP==TRUE, the comparison PLAY_COUNT!=MAX_INTEGER has to be executed on the queue, not the current value which is decremented for a PLAYING Source.

Table 1. Source LOOP_LOKI Attribute

NameSignatureValuesDefault
LOOP_LOKIb TRUE FALSE FALSE
Description: TRUE indicates that the Source will perform an inifinite loop over the content of the current Buffer it refers to.

Loki Byte Offset Extension

The following has been obsoleted by explicit Source State query. hack.

Table 2. Buffer BYTE Offset attribute

NameSignatureValuesDefault
BYTE_LOKIui n/a n/a
Current byte for the buffer bound to the source interpreted as an offset from the beginning of the buffer.