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

[Chris Robinson]

On Sunday 24 February 2008 10:56:40 pm Sherief N. Farouk wrote:
> > The "vagueness" of a just-created buffer is similar to the vagueness of a
> > just-created texture in GL. It creates the object, but doesn't allocate
> > any storage for it, which is what alBufferData is for.
>
> And GL people realized this is A Bad Idea, and they moved away from it for
> GL 3.0. In GL 3.0, a texture has its dimensions and type specified on
> creation and are immutable attributes.

I'm not too sure how I feel about that. I like being able to reuse buffers by 
specifying a new size/format without having to destroy/recreate it. Some 
audio sources can also work with variable length input streams (eg. capture, 
or a real-time network audio stream), and forcing a specific buffer size 
would cause problems. And when dealing with end-of-stream where you might not 
even have enough to fill a buffer...

> >>: It is, but that's not "would have to be" situation. It's the most
> >>: flexible IMO:
>
> If the formats are the same, a pointer to the internal buffer will be
> given. If not, the implementation gets To hand the application the pointer,
> which it could have allocated from a commonly used pool or even in DMA
> region if HW supports it. In short, the implementation knows better is a
> safe assumption to make. And if some HW pops up with native VORBIS support,
> say, the interface still supports maximum performance on that.

True, however...

> > That's not even getting into how hardware may be representing it. In GL,
> > you can't get directly to texture data for the same reason. You'd map a
> > pixel buffer object, read/write it, and call glTexImage*D to
> > transfer/convert from the pixel buffer to the texture, server-side.
>
> Again, GL people are steering away from that in GL3.0.

Letting the implementation dictate its own internal storage format is 
something that really helps with where CPU usage is concerned. GL these days 
is being targetted for pretty strong/dedicated hardware, so "minor" 
inefficiencies may not be as big of a deal. But since audio doesn't tend to 
have dedicated hardware (and indeed people like to argue it doesn't need it, 
even though I don't agree), being able to keep the actual internal sample 
format away from the app would help mixer efficiency, which is a good thing. 
It's hard enough to do what it already does efficiently, and forcing more 
stringent storage specifications won't help.

> >>: I'd go for the standard buffer, instead of introducing a new type.
> >>: Unified buffers are cleaner IMO, and that can be managed via "usage
> >>: flags" for buffers, like READ, WRITE, READ_WRITE.

We can do both. The FBO extension added the render buffer at the same time as 
allowing texture targets. I suppose the reason being that a render buffer 
could be set up in a more efficient manner (since the actual storage is 
hidden), whereas a texture could require some extra processor time to make 
sure it's written correctly with zero-copying to be used as a texture. Render 
buffers and double/tripled as depth/stencil storage.

> OK, this one was a slideshow rip-out, so terminology wasn't explained.
> Varying buffers have nothing to do with GL's use of the term. Varying
> buffers are persistent: Whatever you write to them will still be there the
> next time the shader executes. Varying buffers are a per-source attribute.

Ah, I see. Yeah, that could be useful for some stuff (eg. being able to do 
reverb entirely in shaders).

> > 1) Source shader gets access to the given source's and its
> > listener/context attributes. The shader would be responsible for
> > translating and rotating the source position, setting the gain (as
> > determined by distance, cones, etc), and the pitch (as determined by
> > velocities). It could also write out pairs of attributes that the
> > listener shader would get interpolated (varyings). Multi-channel buffers
> > would only be affected by the pitch and gain.
>
> Why treat multi channel differently? Whatever the user wants to apply to
> the data, he can do it.

Because spatialization doesn't really make sense for multi-channel buffers. A 
single-channel/mono buffer would be "generated" from a single point in space. 
But how would the different channels of a multi-channel buffer map to a 3d 
world through a single source? How would the channels react as the source is 
moved around?

You'd still have the info though, so if you needed, you could still do 
distance attenuation and doppler shift. But panning doesn't make sense.

> > 2) The listener shader gets the current sampler position, gain, and can
> > sample from the source's buffer. It would be expected to sample from the
> > buffer, apply the gain, and write out a sample that is spatialized and
> > mixed. Multi-channel buffers would bypass the listener shader completely.
>
> Again, why exceptions for multichannel here? One of the channels could
> actually be sort of a lookup-table (think vertex attributes in GL), and not
> actual audio data per se.

This would probably better serve through a multibuffer (multitexture-like) 
extension. The problem here would be being able to not only sample from a 
buffer that can have an indeterminate number of channels (currently up to 8) 
with I'd assume 4-float components, but to also write them out without 
worrying about/knowing the number of output channels.