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

[Chris Robinson]

On Monday 25 February 2008 12:31:37 pm Sherief N. Farouk wrote:
> >>: 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.

You want there to be a constant shadow memory buffer in the AL buffer that the 
app can't control? That's even more of a problem for kernel modules/sound 
card drivers, I think, being that it's more persistant. And the dynamic 
allocation problem may still be present anyway, for implementations that try 
to keep unused memory down.

IMO, an app should be able to have control over such memory use. It shouldn't 
have to guess if a function call may or may not create an associated shadow 
buffer with no control over it. If an app has trouble with not enough memory 
because of AL, the implementaiton should be worked on to have a smaller 
memory footprint, not by potentially having memory the app can't control.

> > >>>: 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.

So an implementation that uses an esoteric internal buffer storage format but 
mixes to a more conventional 16-bit interlaced format shouldn't be able to do 
render-to-buffer at all? And how would this work, eg. with 5.1 formats? In 
AL_EXT_MCFORMATS and Windows, the channel order is different than other 
systems.

For example on Windows, OpenAL Soft writes fr/fr/cntr/lfe/bl/br, whereas on 
other systems it writes fr/fl/bl/br/cntr/lfe. A 5.1 buffer always has to be 
in the Windows-style order, but the mixer doesn't necessarilly write it out 
that way. Such OS dependancy isn't nice.

In comparison, a render buffer wouldn't need to use any specific format. It 
could be given a hint when created, but the actual rendering can be done in a 
mixer-efficient way. An app could then read from it and specify the format it 
should be presented as (converting as needed).

> 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?

The first, just with the fixed-function bypassed when the corresponding shader 
is active, and the 3D positioning being calculated after the source shader 
(eg. a vector -> array of gains, to be applied to the result of the listener 
shader). Being able to change the 3d position per sample, while potentially 
nice, is hardly practical in software or even in today's sound hardware I'd 
imagine. It can probably be revisited if hardware shaders ever become 
mainstream.