[Openal-devel] the future of ALUT

[Ryan C. Gordon]

> HOWEVER, as I said in the document, we can (with a little behind-the-scenes
> dancing around) make ALUT 1.0.0 behave like ALUT 0.x.x whilst still 
> cleaning
> things up.

I'm just saying, it feels like we're doing a LOT of tapdancing just to 
keep an entry point named "alutInit".

> But again, what happens in stoopid Windoze?

Unlike Unix, where the user "wants" to use command lines, it's not 
unreasonable on Windows and MacOS to set a default in a control panel, 
so you can reasonably assume that if the program asks for a default 
device (NULL), the AL will pick what the user explicitly asked for 
elsewhere.

> Well, that's why I wanted to have the API pass data DIRECTLY to OpenAL
> and return an alBuffer handle.  That way, we can handle any realtime
> unpacking issues on-the-fly and use extensions if any are present without
> horribly complexifying the average application.

The problem is that if you uncompress the data and hand it to the AL in 
one buffer, in most cases all that memory is still being used by the 
process, just inside the AL instead of in the app...plus between the 
call to alBufferData and the free()'ing of the app's copy, there is 
twice as much allocated.. Buffer queueing just lets us feed the 
uncompressed data in chunks, and leave the rest to be decoded as needed.

The problems there are, of course:
1) It adds complexity.
2) You can't do it in a single buffer handle (you need at least two, and 
requeue them as they are processed by the AL).
3) You have to monitor the buffer handles to see if it's time to 
decompress more and requeue it.

In some cases, you can dodge (i.e. - the AL supports AL_EXT_vorbis, then 
you can just feed that .ogg file to alBufferData in its original form, 
and it'll handle this behind the scenes on a single buffer handle), but 
not in any reliable way across implementations and file formats.

I don't have a good solution here, I'm just making sure you're aware of 
the issue.

--ryan.