Jump to content
  • Advertisement
  • entries
    205
  • comments
    228
  • views
    113473

At long last!!

Sign in to follow this  
Mike Bossy

136 views

For the past few days I've still been trying to figure out my DirectMusic issues and I have finally reached the real solution. I've gone through every possible scenario of what could be causing the bug but no fix seemed to solve the problem. It ends up the problem was that I assumed too much about the API which led to a dumb bone headed error.

So to give a quick synopsis of how my engine handles wave files loaded from disk.

1. Create a DMusic segment using the Loader method LoadObjectFromFile()
2. Download the segment to the performance object and store a pointer to the segment in my wrapper class.
3. When I shut down I unload the segments and then release them.

My assumption of what was happening was that the segment was a chunk of memory that gets allocated upon creation and the gets deallocated upon release. Because after all I'm not passing it a buffer nor do I get a buffer back.

So I went about doing a similar thing when loading wave files from memory.

1. Load the data into a freshly allocated memory buffer.
2. Create a DMusic segment using the Loader method GetObject().
3. Delete the buffer since I assumed that the segment now had a copy of the data.
4. Download the segment to the performance object and store a pointer to the segment in my wrapper class.
5. When I shut down I unload the segments and then release them.

Of course my assumptions were incorrect and somewhere behind the scenes LoadObjectFromFile() creates a buffer somewhere that the segment points to and isn't actually part of the segment. I'm not sure how it gets cleaned up on shutdown but it must.

So when I cleared my buffer in step #3 above my segment was now pointing to what was basically a random chunk of memory. It's amazing that I had any sound working at all but such is the magic of memory allocations.

What made me take so long in getting down to the final solution is that the only example usage of GetObject() that I could find loaded data from a resource using LoadResource() and not just a byte buffer. It ends up that LoadResource() handles magic buffers for you automatically.

So what have I learned from all this wasted time? Don't assume that you know what's going on in a black box!!! And next time when debugging something that might be a weird memory bug comment out the deallocation steps and see if that fixes things. It's ok to leak memory to test out a theory!!!
Sign in to follow this  


1 Comment


Recommended Comments

Hi, my name is Hwee Miin, a programmer from singapore.

I've encounter similar problem with DirectMusic, hope you wouldn't mind to share your experience on the problem to me.

following is what I did:
1. Allocate a buffer.
2. Read wave data from file into the buffer.
3. Pass the buffer to IDirectMusicLoader8::GetObject() to create a segment.

So the problem I facing is when should I free the buffer? According to DirectX SDK, the buffer should not be released before IDirectMusicLoader8 is released because we never knew when the loader need access to the buffer, so even I knew that after some point of my application I won't need that music segment again, I still cannot release that buffer, as I still need the loader to load and play other wave file, which results in a lot of memory wastage.

I've tried to ignore the warning in the DirectX SDK, by releasing the music segment and delete the buffer before IDirectMusicLoader8 is released. But then if I try to reload the same wave file, IDirectMusicSegment8::Dowload() will return me E_FAIL.

Got any suggestion? thanks.

Quote:
Original post by Mike Bossy
For the past few days I've still been trying to figure out my DirectMusic issues and I have finally reached the real solution. I've gone through every possible scenario of what could be causing the bug but no fix seemed to solve the problem. It ends up the problem was that I assumed too much about the API which led to a dumb bone headed error.

So to give a quick synopsis of how my engine handles wave files loaded from disk.

1. Create a DMusic segment using the Loader method LoadObjectFromFile()
2. Download the segment to the performance object and store a pointer to the segment in my wrapper class.
3. When I shut down I unload the segments and then release them.

My assumption of what was happening was that the segment was a chunk of memory that gets allocated upon creation and the gets deallocated upon release. Because after all I'm not passing it a buffer nor do I get a buffer back.

So I went about doing a similar thing when loading wave files from memory.

1. Load the data into a freshly allocated memory buffer.
2. Create a DMusic segment using the Loader method GetObject().
3. Delete the buffer since I assumed that the segment now had a copy of the data.
4. Download the segment to the performance object and store a pointer to the segment in my wrapper class.
5. When I shut down I unload the segments and then release them.

Of course my assumptions were incorrect and somewhere behind the scenes LoadObjectFromFile() creates a buffer somewhere that the segment points to and isn't actually part of the segment. I'm not sure how it gets cleaned up on shutdown but it must.

So when I cleared my buffer in step #3 above my segment was now pointing to what was basically a random chunk of memory. It's amazing that I had any sound working at all but such is the magic of memory allocations.

What made me take so long in getting down to the final solution is that the only example usage of GetObject() that I could find loaded data from a resource using LoadResource() and not just a byte buffer. It ends up that LoadResource() handles magic buffers for you automatically.

So what have I learned from all this wasted time? Don't assume that you know what's going on in a black box!!! And next time when debugging something that might be a weird memory bug comment out the deallocation steps and see if that fixes things. It's ok to leak memory to test out a theory!!!


Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!