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

[Sherief N. Farouk]

Making it immutable would require a new extension. I probably wouldn't have 
much of a problem supporting it since I don't think it'd be very difficult. 
All it'd do is remove a single if check and integer assignment, though.

I'd also say that if GL3 is going down the immutable size route, we may want 
to hold off and see how they do it, to get ideas for the API style, etc. And 
maybe even update all of AL itself to 2.0 with a new API styled after GL3 
(depending on how different it is).

>>: I was speaking about a new API from the start.

Since GL doesn't allow you mapped access to texture or framebuffer data, 
there's no reason for it to use a non-literal mapping. You can only map pixel 
buffer objects, which are using the user-specified format since they're not 
used for rendering or texturing and thus don't need to be in a 
performance-minded format. I don't see any reason to break from this for AL.

>>: PBOs are used for texture transfers. And they perform conversions on read/write on NV GPUs. And let's just ignore GL for the rest of this talk, and argue as if it never existed, for the sake of let's-break-from-it.

Yes, but that's why you'd only load the buffer once as soon as possible (like 
on level/object loads), and reuse it for different sources while you continue 
to need it. You wouldn't refill it every time something new needs it. For 
embedded type systems, you'd probably store it in a specific format for the 
implementation and use some client_storage like extension to keep memory 
duplications down.

>>: When you have 30 sources, each playing an OGG file, and limited memory that you have to stream the decompression, You can't really do that. Try using appverifier and give your sound application 8 MBs of memory or less, see how you'll handle that. With 192MBs where you have to fit a game, 8MB is actually generous.

Because IMO, mapping should just map the data into user space (as is what GL 
does), not convert it inline to whatever the app wants. If you map some data 
so it has to be converted, it may not be able to convert it in the buffer (or 
if it can, may not be optimal).. instead it would have to create a temporary 
buffer *somewhere*, convert it to there, then pass that to the application. 
All this is done behind the programs back, which takes away control from it.

>>: GL does logical mapping: Mapping a PBO for read doesn't mean you're reading the internal format.

I think buffer data conversions should happen in one place: alBufferData (and 
a future alGetBufferData-like function). There, it's converted to/from 
whatever the mixer likes, and the mixer can do whatever it likes with it. 
User functions shouldn't behave differently depending on implementation 
details (this was a short-coming of DirectSound we don't need to copy). The 
fewer gotcha's the better.

>>: alBufferData should be shot and left to day. But being a nice person I am, I'm providing a high performance replacement :D

- Sherief