| | 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. | Pending |
| | 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?) | Pending |
| | 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 | | Pending |
| | 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 |
| | Patrick Dugan | OpenAL should allow for callbacks to perform CPU processing of audio buffers. The ability to add in your own effects into the signal path is common in many other audio engines (XAudio2, FMOD, Wwise, etc). I believe this would provide alot of value for developers using OpenAL. | Pending |
| | Raks | Can you please add 6.1ch support to the next driver update for vista 64, we all would appreciate if this could be done since most of us still use 6.1ch speaker + amp systems.
We would be grateful if you could add 6.1ch support to the driver and console manager and any other relating pieces of software for games, music and apps, much appreciated | Pending |
| | Zbigniew L. | Please provide hardware accelerated OpenAL (with EAX5 extensions) library for Linux. For example OpenAL for X-FI on Linux could be good reference start point for porting Windows games to Linux and creating fast sound processing applications. In Linux good OpenAL library could be used for sound scientific applications in a very same way as OpenGL is used now. | Pending |
| | | | Pending |
| | | | Pending |
| | stormfornever | Must be a reset for byte counter of ALC_CAPTURE_SAMPLES | Pending |
| | JernejL | There is very large need for callbacks, such as when the AL_SOURCE_STATE changes, using this i can perform various custom real-time buffer "stitching", for example in some cases i don't want to queue buffers early, but queue them manually when they are needed, this is important for example where you have a source which consists of several buffers and only one of them is looping.
| Pending |
| | DrIDK | | Pending |
| | | It would be good to have control over system volume using some kind of generic OpenAL interface. | Pending |
| | | Make one standard implementation which works across all platforms.
(Preferably without having to change code of my program in order to get it work) | Pending |
| | . | Aureal had it and you took their assets. How about a re-implimentation. | Pending |
| | myself | There should be a 64-version of the driver for the library. Otherwise it beats the purpose of using it under 64-bit Vista/7. | Pending |