Deleting sound - does it stop a playing sound?
In the code I see this:
if ( !sound ) return;
# ifdef POCO_THREAD
// Get SceneManager
Ogre::SceneManager* s = sound->getSceneManager();
Then in the destructor for OgreeOggISound I see this
So not exactly sure if the sound stops, sorry if I sound really dumb, trying to track down some ghost sounds that don't stop playing (most likely my coding fault, but got this idea so wanted to check in on it).
Where do you see that code, which version of the libarary are you using?
Anyway, in the destructor of each concrete sound class there is a call to _release() which in turn calls alcSourceStop() to stop the sound prior to destruction.
Figured out my "ghost sound" issue
Recap - what was happening was this - sounds were playing long after they were supposed to, if the player wasn't close enough to hear them. They'd play when the player got close enough to their distance paramaters. For example - I could fire off some missiles, and when their fuel runs out they explode. Then I'd move the ship forward to where the missiles detonated and then hear the sounds of the explosions, long after the missiles exploded. In big battles this was a huge issue since after them when the player moved around the battle field, sounds would play all over, constantly argh...
What fixed the issue was setting the sounds as streaming in their constructor ->createSound(
So I guess I don't really understand the difference between a streaming sound and a non-straming, a lil help?
Sticky, I saw your reply a moment ago, I don't check these forums much... thanks for trying to assist, hopefully the above helps someone else.
hmm ok so I re-learned what streaming means, don't see how this would solve this issue... strange.
I too don't understand how that has fixed the issue, streaming / non-streaming relates solely to the way the audio data is stored/read when the sound is played, streaming fills audio buffers from disk with small chunks of data during playback, non-streaming loads the entire sound into ram and reads from there. I can see the issue you were having though, do you have a lot of sounds playing? From memory, you would only suffer from that problem when the currently active sound files exceed the number of supported simultaneous source slots, it would then drop into the distance sorting algorithms, I can't see how switching to streaming would affect that??
Not sure of a robust way to handle that, maybe some sort of 'force play' flag..
Thanks for the post, I'll have to test an older version on my wife's laptop - the issue happened on another pc of mine so I'm guessing its universal, but testers didn't really complain too much about the sound bug.