WARNING: This is an unashamed *flame* - so put on your asbestos underwear.
As an OpenAL outsider, I havn't felt qualified to talk at length about
what's wrong - but I think my contributions so far have earned me one
good flame - so listen up and read what I have to say.
Garin Hiebert wrote: (on the main OpenAL list)
Things should be improving shortly on this front. We've got a new,
separate ALUT library to replace the old ALUT, the 1.1 spec is very
solid, and Creative will be revising the Programmer's Guide for 1.1
soon. New SDKs will follow as we get all the new 1.1 stuff together.
The Linux branch is a point of concern -- it's going to take some TLC.
I strongly disagree with this rosy outlook.
There is no room whatever for complacency - and we shouldn't be telling
end users that everything is wonderful...it's not.
OpenAL is a *mess*.
There, I've said it. It's a *mess*.
There are a lot of good solid ideas in there - and there is some good
code for handling those ideas - but the whole thing is spoiled by
a lack of detailed 'polish'. As a long-time OpenGL user (I used the
first alpha implementation over 10 years ago) - it's very clear to me
where that polish has made OpenGL such a great API - and where the lack
of that polish makes OpenAL...*messy*.
I'm not an audio expert - but the problems with OpenAL aren't audio
problems - they are quality-of-API problems...and those are things I
*can* comment on with authority.
ALUT:
~~~~~
You *don't* have a shiney new ALUT library - you have a completely untested
Alpha with no way to compile it under Windows (and maybe under MacOSX). The
code is only a few days old for chrissakes! AFAIK, there are only five
tiny little test programs that have ever been compiled against it. So far,
I've had *one* emailed comment about it! The odds are high that some flavors
of WAV file that used to work under ALUT 0.x.x won't load with my version of
ALUT. We have plenty of work to do yet before you can say that we have
a new ALUT that we could remotely consider shipping.
So let's not be telling everyone that this is a rosy situation...it will
be rosy in a few months - but right now, ALUT is only just barely usable -
and then only by Linux users in all likelyhood.
The 1.1 Specification:
~~~~~~~~~~~~~~~~~~~~~~
The 1.1 spec is far from 'solid'. In just a cursory read through,
I've found (and reported) half a dozen things that are not mentioned...and
I've only just barely started in on OpenAL. The people who wrote
this document missed things out because they think they are 'obvious'.
If I can find that many things wrong with the 20% or so of the API that
I've personally explored in detail - how much else is wrong?
Everything has to be spelled out and nailed down.
The spec as it stands right now is something I wouldn't even have the
nerve to call version 0.0.
The OpenAL API:
~~~~~~~~~~~~~~~
There are still far too many really basic things you can't do, or can't
do easily, or are poorly concieved, in OpenAL.
* There is no way to automatically apply a simple pitch/volume envelope to
a sound.
* The mechanisms surrounding compressed audio formats are poorly thought
out (IMHO).
* The concept of moving the listener around is disasterously dangerous
for numerical precision - this is a really BASIC mistake.
* The lack of matrix operations makes interfacing with OpenGL more of
a pain than it should be.
* The virtual abandonment of the alEnable/alDisable mechanism in favor
of kludgy 'pass zero as an argument to turn this off' is VERY poorly
conceived.
* There needs to be FAR more flexibility in audio input formats. A 'float'
format should certainly be there.
* The treatment of stereo buffers introduces a *nasty* error trap for
casual application writers - this needs to be fixed before 1.1 comes
out.
* Where are the 'alPushAttrib'/'alPopAttrib' mechanisms? I can't write
efficient, portable, higher level libraries without them.
* alBuffer needs to have more 'Get' methods. It really should be possible
to read back the data buffer. Look at what you can do with OpenGL textures,
work by analogy.
...I could go on.
I was involved in the early specifications of OpenGL - and I can tell you
that OpenAL is just not as carefully thought out.
I can see how someone who's been close to OpenAL for the years it's been
worked on would see vast improvements in 1.1 - but as a newcomer with no
history with the project, I can tell you that OpenAL doesn't look so great
from an outsider's perspective.
In a normal situation, you'd be justified in saying "Well, if it's so
terrible - then why aren't you fixing it?"...well...guess what I've
been doing for the last couple of weeks.
When I picked up the library to use a couple of weeks ago, it was in
such a poor state that I (a mere user) was forced to come in and write
specification documents, provide a new implementation of ALUT - just so
I could do something as basic as get an error message when the end user
mistypes a filename!! ...and now I'm combing the specification for
information as fundamental as "What numerical format is AL_MONO8?" - and
not finding it!
When OpenGL was at release 1.0, all of these things were already rock-solid,
yet OpenAL is already at 1.1 and we don't even have a version number that
can reliably be read by the application!
The Implementation(s):
~~~~~~~~~~~~~~~~~~~~~~
The present structure of the OpenAL CVS repository is partly to blame
here.
IMHO, there shouldn't be separate directories for different OS's - that's
just inviting problems that only show up in some versions - and guaranteeing
that more recent versions of the library are only available on some platforms.
The majority of the AL source code should be identical for all platforms - with
just the lowest levels of the code being split out...otherwise, it's maintenance
hell!
Someone who fixes a bug or adds a feature on the Windows version has to go to
considerable trouble to go fix the Linux and Mac versions - and in reality,
that just won't get done. However, if all three versions are right there in
one function (perhaps with a couple of '#ifdef's to allow subtle variations
in code between the various versions) - then it's *MUCH* more likely that
all of the versions will be kept up to date.
OpenGL has something called 'the reference implementation'. It's a version
that does pretty much everything in software. It has two purposes:
1) It's the gold standard against which every other implementation is compared.
If there is a weak spot in the specification document, you can go to the
reference implementation and say "what does *it* do?" - and use that as the
basis of your own implementation - or as the ultimate resource for fixing up
the specification document.
2) Because it's virtually 100% portable, it can be used as a starting point for
actual deliverable implementations.
OpenAL *desperately* needs a reference implementation.
What Would Steve Do?
~~~~~~~~~~~~~~~~~~~~
Personally - if this was my project - I'd put a hold on 1.1, take a step
back and carefully rethink things. I think you have at least another
couple of months work to do on the specification, some serious code
restructuring and cleanup to do - and THEN you can consider implementing
what you have at the end of that process.
It's bad enough that a 1.0 is 'out there' - because it puts a road-block
on fixing some of the more serious problems since we would have to remain
at least basically reverse-compatible with it.
-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@xxxxxxxx http://www.link.com
Home: sjbaker1@xxxxxxxxxxx http://www.sjbaker.org
|
