[OpenAL] API inconsistency between Linux and Windows

[steve]

Panne Sven BenQ MD PBM IPM TPS 4 wrote:
> Well, the "Linux guy" has to admit that (apart from some optimizations by Prakash) there hasn't been that much activity in the Linux (or better "Unix") part of the OpenAL SI. The main reason was that I focused on ALUT (spec + implementation) in the last weeks, but I think that will change. My Grand Master Plan (tm) is roughly as follows:
> 
>  * Wait for a sensible streaming API proposal for ALUT. :-) There have been some discussions and rough sketches, but nothing concrete yet.
> 
>  * Clean up the ALUT implementation a bit further to make it easier to plug in new file formats, OpenAL extensions etc. This should be finished in one or two weeks from now on.
> 
>  * Use automake and libtool for the Linux SI and clean up the autoconf stuff. This will cause some breakage intially due to the various platforms and build variants involved, but these are normal problems during a transition phase which can easily and quickly be solved (nightly builds on various platforms would help here very much => *hint*). The motivation here is that the current build system is not very maintainable and differs subtly from what is "usual" in many respects. This should hopefully be finished around the end of this month.
> 
>  * Make the Linux implementation 1.1 conformant, cleaning up the implementation during that process. This is probably not possible to achieve in one huge sweep, so I propose to do it in a stepwise manner: Pick a feature block (like e.g. error handling, context management, doppler, ...), grab the 1.1 spec and compare it to the implementation in a nitpicking manner. This is where some helping hands would be needed most urgently and where a concrete time schedule is hard to give. So if somebody would like to take a feature block, I'd be more than happy to help, merge pacthes, etc.
> 
> Having rough schedules from Bob and Daniel for their parts would be very helpful, too. (The openal-devel list might be more appropriate for this.)

Very good!

What ALUT needs (IMHO) is a way to use existing, well known, libraries 
for loading some of the trickier formats - but to do so without creating
dependancies on them...so dynamically loading with dlopen/dlsym/dlclose
is called for.

The streaming stuff is harder - mostly because (IMHO) the present OpenAL
implementation is hard to work with.   I think we need some more OpenAL
discussion before launching into ALUT changes.

Automake/Autoconf/libtool - yes, this is an absolute *must*.  It's 
painful to get right - but once it's right it's easy to keep right.

The 1.1 conformancy and cleanup is probably the most urgent thing.  I'll
try to carve out some time to attack at least one part of this.

I guess the most appropriate thing would be for me to surgically remove
the old ALUT code and pull out the resulting dead code from the guts of
OpenAL...stuff that should really never have been there in the first
place.