I’m working with an old windows product experiencing stalls when releasing sounds. I’ve switched to delayed releasing of sound sources until they are either in a ready or error state as suggested in the documentation. However now I am experience streaming thread crashes (FMOD::SystemI::updateStreams). I don’t understand what could happen between the the old and new release times and how to do this safely. I suspect there is some shared resource being used if the same file is loaded again before the release happens. It doesn’t appear that FMOD::Sound pointers are recycled on subsequent loads though.
I suspect the use of FMOD_OPENMEMORY is my problem here as the provided user memory is still getting freed immediately.
Did this end up being the issue?
If not:
- What’s your exact FMOD version?
- Can I get you to use Debug_Initialize to set your logging level to “LEVEL_LOG”, and provide me with a log where the issue occurs?
Unfortunately it’s going to take quite a refactor to get both the sounds and user memory freed at the same time. The version is 4.44.56. This definitely seems like a smoking gun consider the notes in the documentation. We’re using streaming sounds and it’s pretty clear about the memory sticking around until sounds until release 
You may want to try updating to FMOD Ex 4.44.64 and seeing whether that makes any difference, but I agree that based on what you’ve described it sounds like the real solution would be a refactor. Depending on your setup, it may be worth adjusting all streaming sounds to instead be loaded into memory, but I can definitely understand how that might not be possible given memory overhead constraints.
FMOD Ex is also no longer officially supported, so I may not be able to offer much help on any technical issues unless you update to a supported version of FMOD Studio (2.02.00 and up).
Thanks. I’ll post again if pairing the user memory and sound release doesn’t work.