AW: [Openal-devel] The state of OpenAL (Was: Building OpenAL on older (RH7.3) linux?)
garinh at cheesetoast.net
Thu Sep 1 10:24:41 PDT 2005
> With proposed extensions to deal with what happens when an audio
> is unplugged via USB or whatever, it's simply inevitable that the
> *WILL* have to keep a copy of the pristine data sooner or later.
> If you
> download your audio samples into a USB sound peripheral - then someone
> unplugs it and the system is then required to automagically switch
> to a
> backup sound device - you'd better have kept a copy of the pristine
> somewhere in the library!
> You might just as well formalise that and allow a way to read back
> the buffer
You're right, _future_ needs may demand a _future_ change. I'm
simple-minded -- I'm trying to focus on what we're doing right now.
> The consequence of not formalising it is that many applications will
> have to keep a private copy of the data (because they can't read it
In terms of memory waste, pragmatically we have found that people
with these needs can stream data into AL using the queueing
mechanism, thereby avoiding the necessity of having duplicated all
their data. This has been used for (crude, but adequate)
synchronizing with cutscenes, for instance. For our target market
(speaking from Creative's perspective), our decision has worked out
very well -- there are no commercial games that I know of that are
using AL and have all their data duplicated both in AL and in the app.
More information about the Openal-devel