[Openal-devel] the future of ALUT
Ryan C. Gordon
icculus at clutteredmind.org
Tue Aug 23 18:30:08 PDT 2005
> 1) It's a bunch of extensions that aren't guaranteed to be there.
> If you want to program portably (which is probably the reason you're
> using OpenAL in the first place) - then this is crap.
This is not "crap".
In some cases, the AL can handle this better than you ever can.
Case in point: you can't feed the AL 32-bit float PCM. This is what Ogg
Vorbis (and AAC and MP3, if I'm correct) decodes to natively. You can't
feed the AL non-interleaved channels. This is what Ogg Vorbis decodes to
Internally, the AL may be wanting data in exactly this format
(non-interleaved, 32-bit float PCM samples. This isn't a hypothetical
example, this is what Apple's CoreAudio wants).
So, you can always decode Vorbis, convert it to interleaved 16-bit ints,
and feed it to the AL in chunks with buffer queueing. If you can't use
buffer queueing because of alut's design, you can swallow a ton of
virtual memory to decode the whole thing, and then make an extra copy of
the whole thing in alBufferData(). Oh, and lose audio quality to boot,
since you have to clamp to 16-bit ints. And, when you're done, the AL
will internally convert the whole thing back to non-interleaved, 32-bit
floats while the hard disk is swapping memory pages.
Or you can use AL_EXT_vorbis and skip all of this, at least on platforms
that support it.
And ALUT can hide that from the app, making the best choices behind the
scenes based on available extensions so the user (who happens to be
worried about efficiency as well as portability) doesn't have to worry
about any of it.
And in terms of name-calling, I can't fathom why you're willing to make
so many ugly design choices just to hold on to the name "alutInit" but
consider this to be "crap". It's not lip service to say I admire your
passion for this effort, but let's not get _too_ agressive, here.
> 2) It means that the core of OpenAL has to contain the decoding routines
> for all of the popular formats. Since MP3 is IP-encumbered, this can
> never be the solution for the single most popular audio format on the
No, it means the AL can glue to the existing system decoders, since it
already has a knowledge of QuickTime, Windows Media, etc. In such cases,
it can make them available to ALUT.
In other cases, there may be decoding in hardware of The Single Most
Popular Audio Format On The Planet (just like video cards that can have
s3tc textures uploaded directly), and that will definitely only be
accessible through the AL.
I'm not saying "let's put every decoder in AL and expose them as
seperate extensions for ALUT's use" but there are good reasons for
putting SOME in there, especially when the extensions exist already.
And while ALUT can't _rely_ on these extensions, in many cases, there
are serious benefits, in others, it might be "we never wrote this
decoder, but look, one is available anyhow!" which is a benefit too.
> That puts us back to having the app somehow incrementally unpack and
> queue the data itself.
> That's *very* ugly.
the alutUpdate() idea is the most reasonable thus far in these regards.
Most audio APIs (OpenAL included) usually ends up making at least a
small distinction between "static" and "streaming" buffers for this
reason...and yes, almost all of these _are_ ugly.
Like I said, it's something we have to think about.
> What should we do about very ugly things? We should write them once,
> do it right and hide the ugly details inside ALUT. The noobie users
> will never be any the wiser!
And that's what I'm saying, too.
More information about the Openal-devel