When temporary sounds are destroyed they are added to a list of mSoundsToDestroy. Later on in OgreOggSoundManager::update(), if there is anything in this list, it will destroy one sound per call. This makes it very possible for the list of mSoundsToDestroy to get out of hand and be unable to keep up with the number of sounds getting created and destroyed. I think it should be possible to configure the number of sounds that get destroyed per OgreOggSoundManager::update() call. By default it can destroy only one, as it is now, but there needs to be some member so that the user can specify a larger number and some special value that tells it to destroy everything until the list is empty.
On a related note, I noticed that the mSoundsToDestroy container is being created with a hard-coded value of 100. I think this value should also be configurable, probably as another input parameter to OgreOggSoundManager::init().
I'll add a patch once I put something together, but I'd like input on this before anything gets committed.
How or why are you hitting that limit in your application, why do you need to create/destroy soo many sounds
I don't have a problem making the limits configurable if needed, let me know.
Thanks for all your debugging help, I've been rather busy recently so haven't checked the forums for a while, there is a bug/patch tracker on the sourceforge site you can use, having trouble getting to your patches on mediafire at the moment..
The reason the mSoundsToDestroy is too slow is because we have sound effects for people walking around. Meaning every time a character takes a step it plays a very short sound effect based on the surface they are walking on. These sound effects are temporary sounds so they are immediately destroyed after playing. So as you can imagine the number of destroyed sounds can get very high very faster if there are a lot of characters walking around. If you have a better suggestion on how to handle this kind of feature I'm all ears.
I'll start using the bug tracker from now on. I completely forgot there was a sourceforge page.
Now that I've thought about this for a while I've realized this is a problem on my end. I shouldn't be creating so many sounds because it's just a ridiculous number to make the sound manager keep up with. I'm going to have to redesign how we're dealing with creating all of these sounds to limit it to a much smaller number. This might still be a useful feature to add, but I don't really need it at the moment.
I agree, you really don't want to be creating/destroying hundreds of sounds dynamically, you should be able to get away with a fixed pool of re-useable sounds especially as you can't determine a mass of sounds playing at the same time anyway, plus if you are using hardware buffers you only have a finite number of slots anyway. I don't think its a feature which needs much consideration in reality.