| OpenAL Specification and Reference | ||
|---|---|---|
| <<< Previous | Next >>> | |
OpenAL (henceforth, the "AL") is concerned only with rendering audio into an output buffer, and primarily meant for spatialized audio. There is no support for reading audio input from buffers at this time, and no support for MIDI and other components usually associated with audio hardware. Programmers must relay on other mechanisms to obtain audio (e.g. voice) input or generate music.
The AL has three fundamental primitives or objects -- Buffers, Sources, and a single Listener. Each object can be changed independently, the setting of one object does not affect the setting of others. The application can also set modes that affect processing. Modes are set, objects specified, and other AL operations performed by sending commands in the form of function or procedure calls.
Sources store locations, directions, and other attributes of an object in 3D space and have a buffer associated with them for playback. There are normally far more sources defined than buffers. When the program wants to play a sound, it controls execution through a source object. Sources are processed independently from each other.
Buffers store compressed or un-compressed audio data. It is common to initialize a large set of buffers when the program first starts (or at non-critical times during execution -- between levels in a game, for instance). Buffers are referred to by Sources. Data (audio sample data) is associated with buffers.
There is only one listener (per audio context). The listener attributes are similar to source attributes, but are used to represent where the user is hearing the audio from. The influence of all the sources from the perspective of the listener is mixed and played for the user.
As AL is meant to allow for seamless integration with OpenGL code if needed, the AL primitive (scalar) data types mimic the OpenGL data types. Guaranteed minimum sizes are stated for OpenGL data types (see table 2.2 of the OpenGL 1.2 Specification), but the actual choice of C datatype is left to the implementation. All implementations on a given binary architecture, however, must use a common definition of these datatypes.
Note that this table uses explicit AL prefixes for clarity, while they might be omitted from the rest of the document for brevity. GCC equivalents are given for IA32, i.e. a portable and widely available compiler on the most common target architecture.
Table 1. AL Primitive Data Types
| AL Type | Description | GL Type | GCC IA32 |
|---|---|---|---|
| ALboolean | 8-bit boolean | GLboolean | unsigned char |
| ALbyte | signed 8-bit 2's-complement integer | GLbyte | signed char |
| ALubyte | unsigned 8-bit integer | GLubyte | unsigned char |
| ALshort | signed 16-bit 2's-complement integer | GLshort | short |
| ALushort | unsigned 16-bit integer | GLushort | unsigned short |
| ALint | signed 32-bit 2's-complement integer | GLint | int |
| ALuint | unsigned 32-bit integer | GLuint | unsigned int |
| ALsizei | non-negative 32-bit binary integer size | GLsizei | int |
| ALenum | enumerated 32-bit value | GLenum | unsigned int |
| ALbitfield | 32 bit bitfield | GLbitfield | unsigned int |
| ALfloat | 32-bit IEEE754 floating-point | GLfloat | float |
| ALclampf | Same as ALfloat, but in range [0, 1] | GLclampf | float |
| ALdouble | 64-bit IEEE754 floating-point | GLdouble | double |
| ALclampd | Same as ALdouble, but in range [0, 1] | GLclampd | double |
Any representable floating-point value is legal as input to a AL command that requires floating point data. The result of providing a value that is not a floating point number to such a command is unspecified, but must not lead to AL interruption or termination. In IEEE arithmetic, for example, providing a negative zero or a denormalized number to a GL command yields predictable results, while providing an NaN or infinity yields unspecified results.
Some calculations require division. In such cases (including implied divisions required by vector normalizations), a division by zero produces an unspecified result but must not lead to GL interruption or termination.
| <<< Previous | Home | Next >>> |
| Architecture Review and Acknowledgements | AL State |