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

[Sherief N. Farouk]

I can't. But alBufferData is inherently safer, I think. Take the following 
scenario:

alSourceUnqueueBuffers(source, 1, &bid);
ALvoid *buf = alMapBuffer(bid);
if(!buf)
{
    // The !buf may be triggered at any time because this specific
    // implementation had to create a temp memory space for the map, and we
    // ran out (as opposed to just failing to create a dma map for hardware)
    break;
}
write_to(buf);
alUnmapBuffer(buf);
alSourceQueueBuffers(source, 1, &bid);

>>: This scenario is impossible. Look back at the buffer model, and remember that it's a take-all-or-leave-all one. MapBuffer is a part of it. Under the buffer model, buffer type and size is specified on creation, and if it succeeds then the buffer will always have space and alMapBuffer will never return NULL.

As opposed to a reusable one-time allocation the app controls:

>>: I'm proposing a reusable one-time allocation that the IMPLEMENTATION controls. The implementation always knows better.

ALvoid *buf = malloc(buffer_len);
...
// Unlikely to fail in low memory situations since no new allocations are
// needed
alSourceUnqueueBuffers(source, 1, &buf);
write_to(buf);
alBufferData(..., buf);
alSourceQueueBuffers(source, 1, &buf);


The former method also loses out on being able to cleanly stuff the AL buffer 
back into the queue, which can cause issues when an app relies on the buffers 
returned by Unqueue. You also need to consider cases where this stuff is 
handled by a kernel module (eg. a sound card driver), where it may have a 
comparitively limited address space mapped to the process (and are shared by 
DMA maps, video drivers, etc), and such allocations can take up precious 
space.

>>: See previous points


> I see. But my point still stands, that we can create render buffers along
> with "mixer buffer objects" as an alternative to using AL buffers as a
> target.
>
> >>>: I fail to see why there should be a distinction. Why can't it simply
> >>>: be one of the proposed buffer usage flags?

The format the mixer writes to may not be compatible with its buffer storage 
format (eg. interlaced vs deinterlaced). In that case, a render buffer could 
be used like a mappable buffer object, and call alBufferData with that using 
a special format identifier to avoid card->cpu->card transfers.

>>: If the format isn't compatible with the buffer storage format, then it should fail, plain and simple. Although I recommend a more forgiving strategy of convert-on-mapping-to-read. Keep in mind that this is how GL does it for RGBA8 (cards store natively in ABGR, for nvidia, IIRC).

> >>>: If you look at the XAL designs, two of them have blending units, one
> >>>: with variable multiplier and one with functionality resembling AL_ADD.
> >>>: Blending was dropped in favor of the more flexible blend0in-shader
> >>>: model. The pipeline we went with is #3.

I don't see why it's not possible to have both. There'd be a queryable number 
of buffer units per source that the fixed-function pipeline can blend, and 
the blending is subsumed when a listener shader is active (which can sample 
from all buffers on a source and do the blending itself).

>>: I'll look into that. So which pipeline are you suggesting now?

- Sherief