I am using loadBankMemory with FMOD_STUDIO_LOAD_MEMORY_POINT to prevent an unnecessary copy when loading sound banks.
To quote the fmod documentation:
"FMOD_STUDIO_LOAD_MEMORY_POINT
This differs from FMOD_STUDIO_LOAD_MEMORY in that FMOD uses the memory as is, without duplicating the memory into its own buffers. Cannot not be freed after load, only after calling Studio::unload."
This implies, that after calling unload on a soundbank, the data is not used anymore and can be freed. In practice I have found this not to be the case. While shutting down my engine, fmod would regularly crash somewhere in the main fmod thread, shortly after I unloaded and released a soundbank.
Even queuing the data and keeping it around till after at least another Studio::System::update() has been called does not fix the crash. However, calling Studio::System::flushCommands() and then deleting the sound bank data seems to be working.
It would be great if you could either fix Studio::unload to actually ensure the data is definitely not going to be used after it returns, or clear up the documentation for FMOD_STUDIO_LOAD_MEMORY_POINT and mention exactly when it is save to delete.
And btw. the sentence quoted from the docs contains a typo.
“…the lifetime of the memory must persist until the bank has been queued for unload and then the unload has been performed. You can ensure the memory is not being freed prematurely by only freeing it after receiving the FMOD_STUDIO_SYSTEM_CALLBACK_BANK_UNLOAD callback.”
If it crashes after the unload callback is fired, then there is an issue.
Great, that was the missing detail. Btw. the fmod forum could really use e-mail notifications for answers (I can’t find such a setting anywhere). Also, it’s hard to find your own posts, it’s not listed anywhere, and clicking on the name of someone just brings you to the main fmod page, instead of an overview of posts by that user.
:unload."