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.
![]() | RFC/000507: |
---|---|
ALlong/ALulong are omitted from the Linux OpenGL Base ABI, and the GL specification. Do we want to go ahead on this, or trail GL? Do we include non-i386 architectures to list sizes explicitely. I.e. do we make the ABI part of our mandate? |
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 |
ALlong | signed 64-bit 2's-complement integer | n/a | long long |
ALulong | unsigned 64-bit integer | n/a | unsigned long long |
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 |
![]() | Annotation on Type Sizes |
---|---|
It would be desirable to guarantee the bit size of AL data types, but this might affect the mapping to OpenGL types for which the OpenGL specification only guarantees a minimum size. |
![]() | Annotation on 64bit integral |
---|---|
It would be desirable to define ulong and long, but again we defer to OpenGL in this decision. |
![]() | Annotation on Enumeration |
---|---|
enum is not a C or C++ enumeration, but implemented as C preprocesor defines. This makes it easier to handle extensions to the AL namespace, in particular in dealing with delays in distributing updated reference headers. |
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 |