Domagoj Saric There are three layers actually. Algorithms (as GIL), file IO (as GIL.IO) and device/audio IO. I personally have a need for all of those. It can be easily argued that the first two do fit into Boost (as audio counterparts of GIL). As for the third 'layer' it need not be such a nightmare as one might think. It wouldn't involve supporting individual hardware devices rather OS API's (such as DirectSound, CoreAudio) which would not be that 'alien' to Boost. If we could have a GUI ('video presentation') library in Boost, why not an 'audio presentation'..?
Oh, I'm not arguing for or against here. But as I understand things, Boost is mere an umbrella organization of a set of individually maintained libraries, though most of them do not materialize from a joint Boost community effort (tools and tool chains do to some extent). They evolve elsewhere by experts in the domain of the library, and then proposed, reviewed and possibly included into Boost. That said, of course a team of Audio developers could form on the Boost mail list, and it wasn't my intent to discourage anything like that. But, I do have some experience as a user of commercial audio packages, and this seems IMHO as a very big project to manage. That's why I suggested to look at alternatives, so one doesn't need to start from zero. Cheers, - Christian