AW: [Openal-devel] The state of OpenAL (Was: Building OpenAL on older (RH7.3) linux?)

[Garin Hiebert]

> With proposed extensions to deal with what happens when an audio  
> device
> is unplugged via USB or whatever, it's simply inevitable that the  
> library
> *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  
> data
> somewhere in the library!
>
> You might just as well formalise that and allow a way to read back  
> the buffer
> data.

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
> back)

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.

Garin