| | 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. | Approved |
| | 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. | Approved |
| | Stephen Baker | alPushMatrix/alPopMatrix/alLoadMatrix, etc...and a way to position sources using said matrices. This would make integration with OpenGL applications *MUCH* simpler. | Approved |
| | 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. | Approved |
| | Stephen Baker | # A wider range of alBufferData types...signed and unsigned, char, short, int, float. | Approved |
| | Stephen Baker | Ability to use all data types for all data setting operations - sending buffer frequencies in 'float' for example. | Approved |
| | 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!! | Approved |
| | Stephen Baker and others | Ability to retrieve audio buffer data after it has been attatched via alBufferData(). | Approved |
| | Ryan Gordon | The ability to detect and respond when the active audio output device has been disconnected from the system. | Approved |
| | Creative | OpenAL could have a generic mechanism for enumerating and making use of the effects capabilities of the active audio device. | Approved |
| | 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. | Approved |
| | 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?) | Approved |
| | Ryan Gordon | # Ryan wants alHint back, for future use... | Approved |
| | Scott Harper | Non-realtime rendering/mixing of 3D scenes. | Approved |
| | 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.). | Approved |
| | 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. | Approved |
| | Creative | | Approved |
| | Creative | | Approved |
| | Creative | Allocation callbacks, usage reporting | Approved |
| | Creative | eliminate unnecessary copying and memory usage | Approved |
| | Creative | | Approved |
| | Creative | | Approved |
| | Sven Panne | alCaptureOpenDevice and alCaptureSamples should use 'number of bytes' instead of 'number of samples'. | Approved |
| | Sven Panne | Throw away the distinction between AL and ALC types. | Approved |
| | Carlo Vogelsang | More realism... | Approved |
| | Creative | negative values cause confusion | Approved |
| | Eugene Stets | That is highly awaited features for most of developers. It's very important point to take everything from the hardware acceleration and to show it's advantages like extremely low latency for example. X-RAM is the best idea i seen so far but it's incomplete without Play/Stop callbacks. We need the swiss knife API so in long term the community can make any "ALchemy" with ease. | Pending |
| | | OpenAL library implementation could compensate for low count of sources implemented in hardware, by "swapping" the sources into inactive list, swapping out sources most distant from the listener, to compensate for limit of simultaneous active sources.
The sources would still advance current position, playback, queve new buffers, etc.. but would not output any samples (null output) until they come back into the listener active range or number of sources decreases under the maximum limit.
| Pending |
| | | OpenAL should have an api to retrieve the precise hardware timer data, this would improve precision of timing simulation in audio system related events and for other related usage.
| Pending |
| | Michael Heilmann | The VBO/PBO system of OpenGL separates the buffer data from its interpretation and offers a very flexible system of manipulating the data in the buffers. OpenAL should employ a similar concept. | Pending |