[Openal-devel] Faster buffer model, and more random stuff

[Sherief N. Farouk]

We've added a simple extension to OpenAL for MacOS X that I think  
might be related to this. Sorry if this is off topic (I haven't read  
through all of the posts), but it seems similar at a cursory glance.

We had requests from developers to provide access to the OAL buffers  
to avoid the copy from the buffer the app is filling which would then  
get copied into the al buffer object.

The extension looks like this:

typedef ALvoid	AL_APIENTRY	(*alBufferDataStaticProcPtr) (const ALint  
bid, ALenum format, ALvoid* data, ALsizei size, ALsizei freq);

So, this works in a similar way to the alBufferData API, except that  
the application owns the memory - it uses the dataPtr the application  
provides directly instead of copying into an internal buffer. The  
application's responsibility is to keep this buffer pointer valid and  
untouched as long as this buffer is in use. So, the contract is  
similar for the applications responsibility with regards to the life  
cycle of an alBuffer (the buffer must not be deleted while it is in  
use by an alSource object)

>>: So developers ARE asking for this :D. 

Chris, let's consider this: I use the word mapping in my own meaning, that I
made up. Why? Because your concept of mapping being actual is POINTLESS.
What the user needs is mapping that BEHAVES, semantically and logically, as
if it's a pointer into the buffer. The implementation is free to convert it
to any internal format for storage as long as changes are reflected when
needed (and for apps that don't read back buffers, that'll be rare). In
addition to avoiding the copy, as the extension above proves IS useful, it
also allows for a bunch of hw/multithreaded optimizations. And rearding low
memory platforms: In games, any avoidable waste is unacceptable; and the PS3
has < 256MB of available memory for the whole game. 8 MB for the audio
system is GENEROUS.

- Sherief