[Solved]Bug? mSoundMap holding bad pointers

kungfoomasta

04-03-2010 05:30:51

I believe I've found a bug. The SoundManager stores a list of Sounds, and Sounds are MovableObjects. However these MovableObjects can be destroyed by the Ogre SceneManager, through deleting SceneNodes, clearing the scene, or cleaning up Ogre, etc. Unless I'm mistaken, it looks like in my app, I destroy the SceneManager, which clears the scene and destroys all MovableObjects, ie the Sounds, and then I later cleanup the OgreOgg SoundManager, which tries to destroy the Sounds. Since the Sounds have already been destroyed, the pointers are invalid and I get a crash.

I didn't see anywhere in OgreOggISound.cpp where the SoundManager is notified to remove itself from the manager's sound map. Both methods to destroying Sounds should be covered, either through Ogre, or through the SoundManager. Not sure what the best implementation for this is.

stickymango

04-03-2010 14:42:56

Hmm, I imagine this is a bug yes, I can see the problem. Maybe I can register a MovableObject::Listener to catch these events.. I'll look into it!

Thanks.

stickymango

04-03-2010 16:54:21

Looking at the code it might be cured by using the plugin version of createSound() i.e. passing a SceneManager as the first parameter, it should go through the appropriate destruction functions, however it is a problem if you use the other function, which I admit I still use :oops:

I'm looking into it and hopefully will find a solution.

kungfoomasta

04-03-2010 18:17:48

Its a little tricky since the MovableObject class only supports 1 listener and I'm using one. :)

What I'm wondering is if the destructor can take a parameter?

~OgreOggISound(bool destroyedByOgre = true);

When the SoundManager destroys a sound it can call

delete sound(false);

Then you could have a function

SoundManager::_notifyOgreDestroyedSound(const std::string& soundName);

Which removes the sound from the SoundMap. This function would only be called if the sound was destroyed by Ogre. I've never had destructors that take arguements, so not sure if this works.. :lol:

stickymango

04-03-2010 20:54:29

Ah, hadn't thought about a single listener limitation :(

Having looked into it a bit, that might prove a bit of a brick wall, it seems that by registering a factory with Ogre then things are handled correctly so maybe I'll need to enforce that use instead of the optional uses currently. :?

kungfoomasta

05-03-2010 00:09:31

It just seems odd, conceptually and in practice, that the creation of a Sound requires an Ogre SceneManager. I like currently how I can create a sound and then put it into a scene by attaching it to a scene node.

Also this might be off topic, but I can't seem to get 3d sounds working. I'm assuming my listener is at 0,0,0. Also note the listener is not attached to any scene node. (could this be the problem?) The following is code from my game:


sn->setRelativePosition(Gaia::Vector3(100,0,-5));

Gaia::Sound* sound = Gaia::Core::getSingletonPtr()->getSoundSystem()->createSound("test","CrowUnitAtk2.wav");
sn->attachSound(sound);
sound->setRelativeToListener(true);
sound->play();


I'm guessing the Listener starts at 0,0,0. Also note I haven't yet attached the Listener to any SceneNode. Could this be the reason? No matter where I position the SceneNode, the sound seems like its not relative to the listener. :(

stickymango

07-03-2010 13:07:51

I agree conceptually it doesn't look or feel right to have to pass a SceneManager to create a sound, but the lib is creating an Ogre-derived scene object which requires a SceneManager for creation, so it makes sense that the user should supply the manager object at the point its created. It could be passed as a constructor parameter or have a separate setter() function but that can easily lead to errors.

I think the mistake I've made is allowing two different creation methods of the library so I'm going to enforce one. I'll try and keep the interface changes to a minimum so existing code shouldn't need changing much, if at all (I have many projects using the SceneManager-less create() method so I'll get a solution working which maintains the current policy).

As for the attenuation problem, provided the sound is mono, what you are doing should work fine. I'll take a look at the code to see if theres some issue with that arrangement but you shouldn't need to attach the sound/listener to a SceneNode as far as I know, it should default to a manually controlled position/orientation setting.

kungfoomasta

09-03-2010 18:56:41

Understood. Do what you feel is best.

And a noob question.. how can I tell if a sound is mono? The sounds I'm using were given to me a long time ago by team members doing some voice acting. I'm no longer in touch with them.

stickymango

09-03-2010 20:56:35

I think a little function may be in order :wink:

SoundRecorder is good for wav's, audacity or meow multisound should show that information too I guess.