[Openal] alutLoadWAVFile

[Stephen J Baker]

Panne Sven Com MD PBM IPM TPS 4 wrote:
> So what about "ALU"? Some time ago there was a (WinDoze-only) alu.h, but it
> has been removed quite some time ago, and AFAIK it was not used very often,
> anyway.

That would work.

So what exactly is in ALUT?

I've checked through the sources (the Linux version).

Right now, according to the header file, ALUT appears to comprise just five functions:

alutInit
alutExit
alutLoadWAVFile
alutLoadWAVMemory
alutUnloadWAV

...that's *it*.

alutInit and alutExit are really trivial. Roughly, they do this...

alutInit:

         alcOpenDevice
         alcCreateContext
         alcMakeContextCurrent

...it does error checking - but provides no clean way to detect that it failed
(yes - that problem again).

alutExit:

         alcGetCurrentContext
         alcGetContextsDevice
         alcMakeContextCurrent ( NULL );
         alcDestroyContext
         alcCloseDevice

...again, with error checking but no error return if anything goes wrong.

They could both use an 'ALboolean' return and use 'aluGetError' to provide
better error reporting.

alutLoadWAVFile and alutLoadWAVMemory also need a better error return
mechanism.  It would be nice to add some other file loaders - and a generic
function to load any kind of audio file that we might want to support using
the magic number to figure out what kind of file we have automatically.

alutUnloadWAV is a one line function with three unused parameters!  It
says 'free(data)' - which is **WRONG**.

There are some other externally visible functions - but no documentation or
header file access:

alutLoadMS_ADPCMData_LOKI
alutLoadRAW_ADPCMData_LOKI
alutLoadIMA_ADPCMData_LOKI

...they aren't used elsewhere - and they use some really nasty back-door
trickery to get into the alBuffer innards...NASTY!...so I presume they are
undocumented LOKI extensions to ALUT that we could/should simply delete.

But even ignoring these _LOKI functions, ALUT makes some calls to 'private'
functions inside the main OpenAL sources, (_alSlurp for example - which is
declared in al_main.c - but not used anywhere other than in ALUT).  I think
those functions should simply be moved out into the ALUT sources and deleted
from the main library.

> That way we could have an alu.h header, aluInit, ... And you're
> right: Coupling the utility library releases to the OpenAL stuff itself
> would not be optimal and SourceForge would be a good choice for hosting the
> project (and you're already fluent in leading "free?lu?"-projects there ;-).

I'd be happy to run such a project if that is the wish of the majority.  But
I wouldn't want to do so against the wishes of OpenAL developers.

I have run many OpenSource projects before - some successful - some less so.
I could find *some* free time to work on it - but not enough to do it all by
myself.

It only takes a couple of days to set up a SourceForge project - then we can
take this discussion out of the OpenAL mailing lists.

Someone in OpenAL developer circles ought then to take the action to remove
ALUT calls from any demo/test programs and replace them with inline code or
ALU calls.  Put a link to the ALU project on the OpenAL home page.

> Initially we should focus on just the stuff ALUT is currently offering
> (init/exit convenience functions, loading sound data), but design the API a
> bit more carefully.

Yes.

As I commented before, I'd like to add some non-trivial support stuff
that people would find useful.  A 'mod' type music player for example.

-----------------------------------------------------------------------
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 at link.com           http://www.link.com
Home: sjbaker1 at airmail.net       http://www.sjbaker.org