[Openal-devel] More ALUT formats

[Chris Robinson]

On Friday 17 October 2008 11:10:52 am Jason Daly wrote:
> Chris Robinson wrote:
> > I'm curious about what other people may think is the best way to do it,
> > though.
>
> I'm not sure.  I never thought adding external dependencies to ALUT was
> a good idea.  It's supposed to be a simple library for doing quick
> examples and tests.  It was never meant to be a full-featured audio
> format library.
>
> Maybe a better idea would be a different add-on library (maybe call it
> OpenAL File Interface or ALFI), one that can link with other 3rd party
> libraries to read various formats, and provide results in OpenAL
> buffers, sources, or whatever.  This way ALUT can stay nice and simple.

Maybe. But it seems a bit wasteful to make a seperate lib/API to do what ALUT 
already does. Creating a new API for loading files for OpenAL would just 
duplicate the work ALUT has already done, and just create another dependancy 
for apps assuming they're using alutInit/alutExit/alutSleep/etc for their own 
purposes. It's simply extending the functionality ALUT's intended to have. 
The only real problem is just reporting the supported formats, as the 
mimetype list isn't very friendly.

> > And if need be, would sweeping changes to reorganize and clean up the
> > internal code be acceptable/a good idea.
>
> Sure, just write a new version of the spec first!  :-)

I mean the internals, that aren't exposed to apps. As far as apps would be 
concerned it'd behave exactly the same, but the internal workings would just 
do it a bit differently.