I’m running into an issue when trying to play some sounds in a very particular situation.
We load everything from memory, never letting FMOD hit the disk. We give FMOD a memory block for the .fev and we use registerMemoryFSB() to register the .fsb.
When playing an event, we cache the EventGroup and the index from where it came from. When replaying the event, we check its validity. If the event is no longer valid, we ask the group for it again using the index.
This is where things go "funny".
If play an event (caching the group & index), then unload the .fsb using unregisterMemoryFSB(), and try to replay the event, the FMOD mixer thread crashes.
This is what happens. We attempt to replay the event, but since it is no longer valid, we call EventGroup::getEventByIndex() which returns FMOD_OK (which it shouldn’t, I believe), and since everything is apparently OK (which it isn’t), we continue, attempt to play the event, but the FMOD mixer thread crashes, as it should, because there is no longer any memory associated with that event.
Now, my question is, should EventGroup::getEventByIndex() return FMOD_ERR_INVALID_HANDLE, or do I somehow have to manually invalidate the (cached) EventGroup handle I keep?
- David Morris-Oliveros asked 10 years ago
Yes, I guess I know what you mean. Whatever came out of that FSB would be invalid after the FSB was unloaded, so any subsequent calls would be "undefined".
When I’m about to call unregisterMemoryFSB(), I run through all my currently active events, check to see if they reference that FSB and invalidate their containers.
I just failed to see that I need to do that with EventGroups too.
One more question. When I call unregisterMemoryFSB() on an FSB, are [b:2rwjcb40]all[/b:2rwjcb40] subsequent calls to any Event & EventGroup method undefined? Or would there be some that would have sensible behaviour, and some that would have undefined behaviour?
In particular, I would be interested in using EventGroup::getUserData() to check the validity of the EventGroup.
When you call unregisterMemoryFSB you have to make sure none of your events are referencing that and are still active.
Otherwise you are basically pulling the rug out from under the event’s feet and that’s why it crashes.
We could look at running through all events that reference that touched the fsb, but i think if we did it might just try to load the fsb from disk again. I suppose we could mark the event as invalid so that it returns an error, but that might be a bad idea if the user actually wanted fmod to try and load the file from disk.
Please login first to submit.