[Openal] ALURE 1.0 is finalized and released!

[Andre Krause]

Sounds awesome ! Fantastic! have not tested it yet, but will do the next time i
update openAL soft.

cheers, Andre



Chris Robinson schrieb:
> Took a while and some features needed to be left on the cutting room floor, 
> but ALURE's API has been finalized and 1.0 has been released.
> 
> http://kcat.strangesoft.net/alure.html
> 
> I have every intention of keeping the API and ABI stable like OpenAL itself, 
> so new versions will work as a drop-in replacement for old ones, and old 
> applications will continue to compile without issue against new versions. New 
> versions may (and likely will) see new functions, but they won't affect apps 
> that don't use them.
> 
> At its core, ALURE can load basic (8- and 16-bit PCM) .wav and .aif files 
> without the assistance of external libs. It can also optionally load and use 
> libsndfile (matching and surpassing the formats provided by ALUT), as well as 
> vorbisfile and libFLAC. Originally I was going to support libmpg123, but it's 
> currently-volatile/broken ABI made loading it dynamically a tricky affair, and 
> I felt it better to leave it out for now so I can make a release with as few 
> potential complications as possible.
> 
> MP3 support will be revisited, and alternative libs considered, however an 
> extendable decoding API is provided so apps can still use MP3 (and other 
> formats) by providing their own library/routines.
> 
> 
> Tentative future plans for the library include:
> * Automatic buffer queueing. An app can provide a source and stream handle, 
> and the library will asynchronously stream the sound through the source for 
> you.
> * Effect loading. Load files (ASCII text describing a particular effect) into 
> EFX effect objects.
> * Bulk sound loading. Load a full directory tree/zip archive into an array of 
> buffers, with the path+filename given back for each for identification, and/or 
> providing a list of filenames and have them all load into an array of buffers.
> * Source management. Use handles to manage OpenAL sources, so that an app 
> needn't be too concerned about what to do when running out of physical 
> sources.. the lib will make sure the most audible are the ones being heard.
> * Scene management. Provide managed sources, listener data, and effect areas, 
> and the lib will make sure the sources closest to the listener are heard, 
> effects will be applied according to the listener and source environments, and 
> be updated in real-time.
> 
> These have been ideas that've burrowed into my head at one point or another, 
> and things will probably change as they get worked on. It will all be 
> optional, however... an app won't have to use scene management if it just 
> wants source management, and an app won't have to use source management if it 
> just wants to load effects and sounds, etc.
> 
> 
> Anyway.. that's my current plans for what to do with the lib. Comments, 
> suggestions, and (constructive) criticisms are, as always, welcome. Quite a 
> few firsts for me in this release, including pre-built win32 binaries... 
> hopefully I didn't mess things up too badly. :)
> 
> - Chris
> _______________________________________________
> Openal mailing list
> Openal at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal
>