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

[Chris Robinson]

Thanks for the reply, Dan. I much appreciate it. :)

On Tuesday 26 February 2008 04:45:57 pm Daniel PEACOCK wrote:
> Hi All,
>
> alBufferData stuff: -
>
> Our XBox360 AL implementation includes an alBufferDataStatic entry point
> that tells AL to read sample data from the location specified.  When you
> use this function, AL does not make a copy of the sample data.   The
> implementation expects the data to always be present, have a suitable
> alignment, and to only be changed / deleted *after* AL has been told that
> it is no longer available (i.e. alBufferDataStatic called again with a
> different pointer, or the Buffer is deleted).   This function is essential
> to 360 developers because it saves memory and reduces the chance for
> fragmentation.  It can also allow a developer to optimize their file
> formats and file loading code.
>
> We are planning to bring this extension to our PC implementations too but
> there are still some things being worked out (not least of which is
> alignment issues).  This does mean that performance optimizations like
> conversion of 8bit to 16bit, or ADPCM decode at alBufferData time will have
> to be deferred till playback under the alBufferDataStatic model.

So is it safe to say we should expect OSX's ALC_EXT_STATIC_BUFFER to move over 
to the PC and other platforms, or would it be a new extension? Is there any 
information on the extension (openal.org's list doesn't have a link for it)?

> Not to dwell on the subject for too long ... but 8 or so years ago when AL
> was being designed it wasn't a horrible idea to pass the audio data to AL
> to be stored in implementation specific format(s).   Audio budgets were
> much smaller and it was much more common to see "load level then play"
> games.   Now we are seeing huge audio asset budgets (at least on disc if
> not memory) and "play while loading" worlds that have to keep a very tight
> reign on memory usage in order to keep the game playable after hours of
> play time.

Just to note, I don't think the current method is at all outdated. At the very 
least for new programmers it's nice to let OpenAL manage the buffer data for 
you. I'd think it also helps in cases for mixers that may not want the data 
as it's usually stored, and in supporting more formats since it can be 
pre-converted on load.

And out of curiousity, how is it expected to work on implementations that 
store the data on dedicated audio memory?

> One of the biggest
> issues we deal with all the time is ...  if we add a super-cool feature to
> a soundcard / AL implementation, the first question from a developer is
> going to be ... "what happens when I run my game that uses your super-cool
> feature, on a non-Creative card / alternative AL implementation?".

I can understand that, and is actually the first thing I think of when I come 
up with an idea for an extension. Having an extension is all well and good, 
but it's not going to be terribly useful if it won't work on other 
OSs/implementations. Thus the only extensions I'd actively push would 
be "niceties" (such as format selection hints) or system specific (like 
texture_from_pixmap is in GL; though there hasn't been any ideas in this 
direction yet..). Things like mapping mono buffers to specific output 
channels is kind of a make-or-break deal.. very nice, IMO, but if a developer 
can't rely on it being there across implementations, it might as well not be 
there.

> Future plans: -
>
> As Jason mentioned, a lot of the new features we are planning to bring to
> AL are in direct response to game developer requests and to help AL remain
> competitive with other APIs.   The plans are focusing on an "EFX 2.0"
> extension that adds custom insert effects and other features to AL.   More
> details to follow.

I'm definitely looking forward to what's coming up. :)