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.
Valid formats for internalFormat are FORMAT_MONO8, FORMAT_MONO16, FORMAT_STEREO8, and FORMAT_STEREO16.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. |
![]() | RFC: 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 ); |
![]() | RFC: 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. |
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 )
The following has been obsoleted by explicit Source State query. hack.
Current byte for the buffer bound to the source interpreted as an offset from the beginning of the buffer.
<<< Previous | Home | Next >>> |
Other Extension | Up | Loop Point Extension |