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

[Sherief N. Farouk]

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

This particular extension was originally created on and for the Xbox 360.
Due to the nature of that device it didn't really appear as a queryable
extension (the 360 developer can rely on it always be present).  It looks
like Apple gave it a friendly name and included it in their implementation.
I think we can probably do the same when we bring it to PC.

> > 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 agree that it is probably simpler and less risky when AL copies the
sample data.  The original alBufferData function will alway be with us for
this purpose.  There are lots of developers requesting the
alBufferDataStatic model so they can control memory - e.g. they can choose
to dedicate 32MB to audio and do whatever they need to do to load sample
sets in and out of that locked RAM to make it work.

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

This transformation of sample data at alBufferData time leads to developer
concerns about memory usage.  e.g. If ADPCM is decoded at alBufferData
time, the assets get 3.6 times as big.  If the developer is less concerned
about memory usage and more worried about run-time performance it would be
better to decode once and play many times.   I guess my point is that,
alBufferDataStatic gives an alternative option to the developer.

> And out of curiousity, how is it expected to work on implementations that

> store the data on dedicated audio memory?

Dedicated audio memory won't be used.   The sample will be read from where
the developer put it - and they probably won't be able to put it on
dedicated audio ram themselves.  alBufferData will be the way to use
dedicated audio RAM.

>>>: On that light, a pitch for MapBuffer:
1) Copy is avoided, yet the implementation gets to manage the buffer. As
people have learned by the time of D3D10, the implementation always does a
better job at managing resources.
2) With MapBuffer, dedicated audio ram can be used transparently, and
without any additional overhead
3) Immutable buffers avoid branching, reallocations and the uncertainness of
alBufferData's success, very useful on a platform like the X-Box 360
4) There is no situation where MapBuffer would cause an extra allocation,
calculation or stall over BufferData
5) I'm willing to bet good money on the fact that the current XAL
implementation (excluding shaders and multiple source streams, features that
OpenAL lacks anyway) will beat ANY OpenAL implementation to the ground in
terms of memory use at least, the beating being much harder on console
platforms (due to the nature of the CPUs on the 360 and PS3). XAL has
immutable buffers and MapBuffer is the only way to transfer data. It's
designed very much in the steps of OpenGL (3.0, from what we've seen/heard
about it), except perhaps for using some C++ additions (like namespaces).
6) Literal mapping of a buffer into the implementation internal format is
pointless, pointless, pointless.

- Sherief