[Openal-devel] the future of ALUT
Ryan C. Gordon
icculus at clutteredmind.org
Tue Aug 23 14:52:51 PDT 2005
> 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
> 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
> 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
More information about the Openal-devel