[Openal-devel] the future of ALUT

[Ryan C. Gordon]

> 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 
by default.

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
>    planet!

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.

--ryan.