OpenAL Operation

OpenAL Fundamentals

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.

NoteRFC: Data Binding
 

Have to specifiy when pointer arguments are dereferenced.

Primitive Types

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.

NoteRFC/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 TypeDescriptionGL TypeGCC 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

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

NoteAnnotation on 64bit integral
 

It would be desirable to define ulong and long, but again we defer to OpenGL in this decision.

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

Floating-Point Computation

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.