Currently we are using OpenAL API for our audio driver, and thanks to the AL_EXT_STATIC_BUFFER extension, at least offered in MACOS X and iOS, we achieved a 2500% gain in performance when transferring audio data.
What is offered by this extension?
Basically the function alBufferDataStatic, that allow us to send to OpenAL directly a memory buffer managed by us, so that OpenAL does not have to reserve extra memory (the corresponding malloc or realloc), and make a copy of our data (memcpy) in its own reserved buffer. Thereby achieving a performance boost (around 2500% in the iPhone).We have seen some controversy on the Internet about using this extension.
On the one hand it is recommended by Apple in their Technical Note: OpenAL FAQ for iPhone OS, but many people (in the Apple forums) seems not to understand well what does this function, misusing it, and therefore do not getting the desired results.
A clear example is to send to OpenAL a buffer (using alBufferDataStatic) and afterwards release it, (which is exactly what you have to do when using alBufferData). In this example, of course, the sound can't be heard well...
Rule of thumb:
If you use alBufferData you must release your memory.
If you use alBufferDataStatic you must handle your memory.
Some bad practices with the use of this function are contained in the blog of Ben Britten: alBufferDataStatic: Why You Should Avoid it, which in our opinion does not say do not use it, but do not use it unless you know exactly what are you doing.
In any case, we have concluded that we are able to reserve a memory buffer and then do not forget to free it, or use it after being released, so we will use it ^_^
