OpenAL - Wishlist

OpenAL

OpenAL Wishlist

OpenAL Wishlist

This is a list of suggestions which have been brought up on the mailing lists or elsewhere which will be considered for a future version of OpenAL. These suggestions may or may not ever be incorporated into OpenAL. The intent of creating this list is to have a starting point for discussion when work on the next specification begins. Discussion on one of the mailing lists may trigger an addition to this list, or you can use our Web Mail Form.

Wishlist Items

  • alEnable/alDisable (Stephen Baker) -- Using the 'convention' of an argument of zero turns something off is ugly for large applications because you can't globally enable or disable something without touching a bazillion lines of code. OpenGL had this right.

  • alPushAttrib/alPopAttrib (Stephen Baker) -- Again, large programs need to be able to save current state - do something weird for a while - then restore the old state with absolute certainty. You might argue that you can do this in the application - but that's nasty to maintain in the presence of extensions to the underlying API...you can't manually save and restore state if new state items appear in extensions.

  • Matrix Operations (Stephen Baker) -- alPushMatrix/alPopMatrix/alLoadMatrix, etc...and a way to position sources using said matrices. This would make integration with OpenGL applications *MUCH* simpler.

  • Deduced Velocities (Stephen Baker) -- I'd like to see an option to have source velocities be deduced automatically from consecutive source positions - given a global 'time step' specified by the application. I can see how not every application would want this - but for those that do, this would be a huge simplification.

  • New alBufferData types (Stephen Baker) -- A wider range of alBufferData types...signed and unsigned, char, short, int, float.

  • Wider Type Support (Stephen Baker) -- Ability to use all data types for all data setting operations - sending buffer frequencies in 'float' for example.

  • Tightening of Limits (Stephen Baker) -- A general tightening up of error handling, limit getting, stuff like that. (eg The AL_PITCH attribute is described as having implementation dependent limits - but there is no alGet to let me find out what those limits are and no guarantee of at least *some* range of pitch variation that every implementation supports!!

  • Retrieval of Buffer Data (Stephen Baker and others) -- Ability to retrieve audio buffer data after it has been attatched via alBufferData().

  • Disconnect Notification and Handling (Ryan Gordon) -- The ability to detect and respond when the active audio output device has been disconnected from the system.

  • Generic Effects (Creative Labs) -- OpenAL could have a generic mechanism for enumerating and making use of the effects capabilities of the active audio device.

  • System CODEC Usage (Bob Aron) -- OpenAL could have a mechanism for discovering and making use of CODECs available on the host system, independent of any built-in support within OpenAL.

  • Really Good Demonstration Program (Stephen Baker) -- Something that an end-user can run which really shows off what OpenAL can do - without distracting him with graphics and other stuff. (Hunt the Wumpus, with reverb and filtering?)

  • alHint (Ryan Gordon) -- Ryan wants alHint back, for future use...

  • Non-Realtime Rendering (Scott Harper) -- Non-realtime rendering/mixing of 3D scenes.

  • Specifying Big/Little Endian Format (Erik Hoffman) -- There should be a way to specify if incoming PCM data is big/little endian. Stephen Baker adds that there should be more formats period (floating point, two's complement, byte-wide, etc.).

  • Envelopes (Stephen Baker) -- The idea is that an envelope (in OpenAL terms) would be a short, and typically very low frequency (1Hz to 5Hz maybe) alBuffer. An envelope could be attached to an alSource to modulate one of it's properties. The most obvious being it's pitch and volume. So you'd add just one extra call to the alSource API -- alSourceEnvelope (ALuint source, ALenum envelope_type, ALuint envelopeBuffer). Envelope_type would be either AL_ENVELOPE_PITCH or AL_ENVELOPE_GAIN. The idea is basically simple - as the main alBuffer is replayed, so are any envelope buffers - with the result of them modifying the alSource's parameters on-the-fly.

  • Multi-channel sources (Creative)

  • 2D panning/speaker level support (Creative)

  • Memory functions (Creative) -- Allocation callbacks, usage reporting

  • Better Buffer Management (Creative) -- eliminate unnecessary copying and memory usage

  • Loop Point Support (Creative)

  • Play/Stop Callbacks (Creative)

  • Capture calls (Sven Panne) -- alCaptureOpenDevice and alCaptureSamples should use 'number of bytes' instead of 'number of samples'.

  • AL/ALC Types (Sven Panne) -- Throw away the distinction between AL and ALC types.

  • Per-source speed of sound, and a listener SoS (Carlo Vogelsang) -- More realism...

  • AL_GAIN should be restricted to non-negative values (Creative) -- negative values cause confusion