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

[Chris Robinson]

On Monday 25 February 2008 07:38:17 pm Sherief N. Farouk wrote:
> >>: I was speaking about a new API from the start.

I'd think any new AL API should be designed after GL3. Unfortunately the 
Khronos group is taking their sweet time with it, and no one really know what 
it's like yet.

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

Since AL is specificly designed to function similarly to GL, I wouldn't see 
that as very conducive.

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

If your app is that strained for memory that you have to stream almost 
everything as Ogg, you'd be better off with hardware that can natively decode 
Ogg. In such a case, there's an extension which lets you load compressed Ogg 
data.

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

A PBO doesn't have an explicit internal format. It's data in the form of 
whatever you wrote to it. That is how it's stored in the PBO, and that's 
what's mapped. When it's used as the basis for GL function pixel data (for 
glTexImage, glReadPixels, etc), you specify the format for it, just as if you 
were using a normal RAM pointer, and GL reads/writes it to the PBO as such.