First chance exception still exist in sound engine

[VirtualAce]

I posted this a long time ago, but I'm still getting a first chance exception in dsound.dll with my music/sound engine.

This only occurs when I run in debug mode. I was wondering if any of you have run into the same problem with DirectMusic? Perhaps this is a known bug, although I can't find any info about it at msdn.

It's very strange because after my engine shuts down I can play any retail game and it runs flawlessly. So I'm not sure MSVC is reporting this error correctly. Also inside of the game, my music and sound work perfect - and others have also used my code and it is working with their games as well.

Something is amiss somewhere but I have no starting point on where to begin debugging.

I will again post the source files for the sound portion. Please if you have time and understand DirectMusic and also the STL, let me know if you see any code that might be causing this exception.

Feel free to use this code to put sound in your games.

[MrWizard]

What are the steps to reproduce the exception? I just tried loading up a wave and I didn't see one thrown. Using VC6 here. But I do get a crash if I load a sound and never play it because SegState will be null and you try to call Release on it.

A few notes while I wait for a response:

-Why do you use SAFE_RELEASE in some places and not in others?

-Do you know about the CComPtr template class? If not, look into it.

-You use 'if (hr)' to check for failure when you load a sound. However, other places you use the prefered method of FAILED or SUCCEEDED.

-No SetVolume implementation?

-In CDXSoundEmitter::LoadSound, if there is an error loading the sound file then the following line will cause an access violation.

temp.Segment->Download(Performance);

-In places when you access into the Sounds vector, you do no bounds checking. You should do a check before hand on the id and handle it yourself if it is invalid or you should use the at() method provided by std::vector which will throw an assert if you are out of bounds.

[VirtualAce]

What are the steps to reproduce the exception? I just tried loading up a wave and I didn't see one thrown. Using VC6 here. But I do get a crash if I load a sound and never play it because SegState will be null and you try to call Release on it.

This is probably where the exception is coming from. In XSpace I load 6 songs for the home sector. What is probably occuring is that not all songs have been played before I exit and this the system is calling Release() on SegStates that are NULL. Not a good thing. Thanks for pointing this out.

The answers to your questions:

-Why do you use SAFE_RELEASE in some places and not in others?

SAFE_RELEASE was not always part of the code base and I'm still switching it all over so that it uses this macro exclusively.

-Do you know about the CComPtr template class? If not, look into it.

No I don't know anything about it. I'm assuming it has to do with safe creation and deletion of COM objects as it relates to pointers instead of those created on the stack.

-You use 'if (hr)' to check for failure when you load a sound. However, other places you use the prefered method of FAILED or SUCCEEDED.

Again a result of switching the code to use FAILED and SUCCEEDED. However, I do not believe this is causing any issues.

-No SetVolume implementation?

You cannot set the volume on a primary buffer or secondary buffer without first implementing or using audio paths. The audio path interface will then allow you to access the buffer interface which will then expose numerous more functions and interfaces for operations on buffers. As of yet, I've not implemented a wrapper class for IDirectMusicAudioPath.

-In CDXSoundEmitter::LoadSound, if there is an error loading the sound file then the following line will cause an access violation.

Code:
temp.Segment->Download(Performance);

I thought that I checked to see if the load sound function succeeded, and if it did it will download. I will look into this again.

-In places when you access into the Sounds vector, you do no bounds checking. You should do a check before hand on the id and handle it yourself if it is invalid or you should use the at() method provided by std::vector which will throw an assert if you are out of bounds.

This was done on purpose. I do no bounds checking simply to save frame rates. The way the system works is that all sounds that need to be used, and all music that needs to be used will be in memory - if the user has loaded them correctly and if the load sound function has succeeded. This will return an ID to the user and that ID is valid until the system is shut down. You cannot remove songs or sound effects from the vector, which is why direct access to the vector is not allowed. The ID's should be valid at all times as long as the loading portion succeeded.
This design was chosen simply because I didn't see much need to remove sound effects and music from memory during gameplay as this would certainly cause issues with frame rates and/or multiplay when it is implemented. Since memory is really not a concern anymore, I didn't see the use in creating a delete or remove function. Notice that the user CANNOT remove or add anything to the vector unless they use the wrapper class functions. All access to the vector is only allowed through the class functions which allows me specific control over what is being done with the vector at any one time. So to use this correctly one would load all sounds and music pertinent to the current level, world, etc, being played and then play those items when needed during the gameplay. Once the level has been completed, the system would be shut down. If on the occasion the user attempts to play a sound or access a sound via an invalid ID then in my opinion that is the user's fault and not mine, the designer's. I leave correct usage of the system up to the user similar to the way that C does no bounds checking on arrays. It is the programmer's responsibility to do this and to check that they are within the bounds of the array, or in my case, the vector. This will not be changed simply to support lazy programmers and/or programmers who probably shouldn't be using the code base in the first place. Hint: Don't attempt to access any sounds with a made up or fake ID. It will certainly result in a major crash.

Even if I implemented at() this would throw an exception and the whole thing would still come crashing down - so whether a first class exception is thrown or an access violation occurs because of my code catching an incorrect ID or because of someone else's code trying to access the vector with an invalid ID - is pretty much the same thing. Either way it's going to crash.

I realize that I need to create a shutdown function that in fact does not release the interfaces so that one could reset the system at the end of a level or world and would not have to re-initialize the entire system.


Thanks for the input. It is greatly appreciated.