[Openal-devel] Map/Unmap API

[Chris Robinson]

Since the subject of OpenAL 1.2 has come up a couple times, perhaps this 
should be discussed (again?).

In OpenGL, you can create PBOs to store pixel data to read from and write to 
textures and render surfaces. It allows for fast access as calls like 
glTexImage2D and co. can be scheduled to occur later and via DMA transfers. It 
also allows an app to map/unmap it to read and/or write quickly.

Something like this could be useful to OpenAL too, I think. Often times when 
audio is decompressed, it requires the app to have a memory segment to write 
to and give to alBufferData. Since alBufferData needs to finish with the user 
pointer before returning, this would cause unnecessary waiting while it's 
copied and potentially converted. This would also be an issue for real-time 
generated streamed sounds.


I don't think it would be too difficult to implement a basic proof-of-concept. 
I would only ask how it would be named, since OpenGL's use of 'Buffer' is 
already taken. It could be given a name like 'Databuffer' (kind of wordy) with 
a new set of functions, or override OpenAL's buffers to behave that way when 
alBufferData is called with AL_NONE for a format with a couple new functions 
to handle it. With the latter, the frequency would be ignored, buffers that 
use AL_NONE can't be queued or attached to a source, and buffers that don't 
use AL_NONE can't be 'bound'. Reading the AL_SIZE property would work as 
expected, and AL_CHANNELS/AL_BITS/AL_FREQUENCY would give 0.


Thoughts, comments? If there's no serious objections, I'll try playing around 
with the idea.