I've started to work with OpenAL and did the most basic setup och device and context. It now seems that the number of sources are limited to 32. In my application this is a problem since nearly all objects (mostly vehicles) in the world has a sound attached to them. And when a lot of other sounds are generated the sources will run out and thus I need some way of handling this. I have read something about having a pool of sources but what strategies are to be applied to determine what sources should be allowed to play. When a new sound is generated and all sources are in use one og them need to be stopped and used for the new sound. To conclude my question a little, what is the most common way of handling this limitation of 32 sources?

First ask yourself if you really _need_ more than 32 sources, if it's really worth it. Sound output will be hardly meaningful if there are lots and lots of sounds and the user isn't able to distinguish them. In a scenery like yours, many engines will probably be some rumble-rumble and you could easily play just the sounds near to the listener without much (or any) impact on the result.

To decide which source to stop, you can try some kind of priority system, where you take out the less important source at that time. What is "important" may vary, you could choose the one that has played longer, the most distant/lower volume sound source or even kick one out randomly :) Probably background music shouldn't be included in this 'swap list', most people get mad when the music stops.

Another option is mixing the sounds yourself before feeding the data to OpenAL. You could also try OpenAL soft, which seems to have a source limit of 256.

Basically, you need to allocate the sources based on some priority metric,for example volume (or, since you have positional sources-> distance) or some artist-set metric (gameplay-relevant sounds should always take priority over atmosphere-only sounds) etc.

You may want to make sure, that any sound that is interrupted by a higher priority sound is only interrupted at the next zero-crossing to prevent clicking.

A limit of 256 would be very much sufficient. Is it a large overhead using this instead of the default which I guess is hardware mixing?

I was also thinking about some kind of priority based on volume, distance and other properties.

Quote:Is it a large overhead using this instead of the default which I guess is hardware mixing?

The 'default' is Creative's implementation, which will fall back to a software mixer if the system doesn't meet the requirements for a hardware approach.

Your best bet is to try it out :)