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

[Sherief N. Farouk]

When buffering data, an implementation is free to not resize the memory 
segment if the new data is smaller than the current, as long as it'll behave 
as expected. And even if it did, decreasing a memory segment's size is very 
cheap. And as I'd be hard pressed to believe someone would need to update a 
buffer queue more than 5 to 10 times a second, this isn't going to be a 
bottleneck compared to the actual audio mixing or Ogg decoding.

>>: The immutable buffer approach makes it free, instead of "relatively cheap". Note that "relatively cheap" thinking on the implementation side uses lots of branching statements that are MURDER on some of the platforms we work on, and anything without Out of order execution, basically.
And with shaders and a scene with lots of sources, buffers get filled much more that 10 times per second (@ 60 fps).

Then how do you deal with the fact that data may not be in a format known by 
the app? It couldn't know the mapped buffer is, eg. 24-bit signed integer 
with 8-bit padding, as opposed to the float-32 it created the buffer with, or 
that the data is deinterlaced and possibly in completely different memory 
segments. Converting on (un)map, I think is beyond the scope of what mapping 
is for, let alone that it wouldn't even be possible if the mapped buffer 
memory is smaller than the pre-converted data.

>>: Again, this is a convert-on-read. You seem to treat mapping as a direct, literal mapping. It's not. It's more logical than you treat it. It BEHAVES like it's stored in memory in that format. Regardless of the internal format, a buffer created with format X (the implementation can store it in any format it deems suitable, mind you) expects data to be written to the pointer provided by map buffer in the format X, and provides a pointer pointing to data in the format X when a mapping is requested for read. Conversion is done when necessary. Again, think nvidia GPUs and RGBA.

With BufferData though, you know exactly what it's going to do at any given 
time: (re)allocate buffer storage for itself, and copy/convert the given 
buffer data to an internal representation.

>>: It's not really useful to know exactly that it's gonna do a bad thing all the time :D. You have no idea how painful (and plain outright wrong) is it to allocate memory in your main game loop. It hurts on PC, it's a lot more painful on consoles. Just see some of Pete Isensee's talks on that.

The mixer already "converts" from Windows' mixed up channel ordering on read. 
AL_FORMAT_51CHN* needs the data in Windows' ordering, and any data in its 
buffer needs to be the same. If a mixer wrote non-Windows ordering, mixing 
the resulting buffer would get the channel order wrong, which is why it needs 
to be written correctly. You'd need a new format type for a different 
ordering for the mixer to recognize it, but that raises the complexity of the 
mixer since it can currently assume a specific channel order and data layout 
for any given channel count.

In GL, this is why you don't get direct access to texture memory. You can 
specify RGB8, but it can store it in X2BGR10, or XBGR8, or whatever it feels 
like as long as it has the expected precision and functionality. A pixel 
buffer object is not converted when you map/unmap it, but the corresponding 
gl[Get]TexImage* when reading from/writing to it does convert it.

>>: I still fail to see why a user-transparent flow of:
Create buffer in AL_STEREO_32F format
Set as source output target
play source
Map buffer for read
Isn't the choice. The driver can do all the necessary conversions in the background, implementations do what they see best and all's transparent from the user..

- Sherief