[Openal-devel] Faster buffer model, and more random stuff
Sherief N. Farouk
sherief at mganin.com
Tue Feb 26 12:45:27 PST 2008
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.
More information about the Openal-devel