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

[Daniel PEACOCK]

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.

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.


Responses to extensions: -

This is tricky - in an ideal world I would love to spend more time
responding to the many great ideas that come from this list.   Part of the
problem is that there are "many great ideas" and is hard to find the time
to process each one and think them through especially as a lot of time is
being spent 'supporting' the current set of features.   Not only that - but
even if we see a great idea, and agree to implement it, we have the
additional concerns / problems / challenges to make it work on our various
AL implementations (hardware and software based).   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 will endeavour to provide more feedback on future extension proposals.


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.


Dan
Creative Labs, Inc.

Notice
The information in this message is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
message by anyone else is unauthorized.  If you are not the intended
recipient,  any disclosure,  copying or distribution of the message,  or
any action taken by you in reliance on it,  is prohibited and may be
unlawful.  If you have received this message in error,  please delete it
and contact the sender immediately.  Thank you.