|
Home
About
Platforms
Links
Documentation
Downloads
Mailing Lists
|
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
|