I’ve had a few editor freezes when live-recompiling code, and when checking the source, it appeared that every freeze was caused by a fmod external call.
The last one was caused by a unity exception thrown on DEBUG_CALLBACK
The stack was:
Resources.Load
Initialize
Settings.Instance
DebugLogWarning
DEBUG_CALLBACK
(had to do it from memory since I didn’t copy the code)
Resources.Load cannot be called from the fmod callback thread. This could be fixed by just modifying Instance.Initialize to something like:
internal static void Initialize()
{
if (instance == null)
{
isInitializing = true;
instance = null;
// TODO: create issue about this in fmod forum
try
{
instance = Resources.Load(SettingsAssetName) as Settings;
}
catch (Exception e)
{
// This call will not recursively call Initialize() again since isInitializing is set to true.
RuntimeUtils.DebugLog($"[FMOD] Tried to init Settings instance from wrong thread: {e}");
isInitializing = false;
return;
}
if (instance == null)
{
RuntimeUtils.DebugLog("[FMOD] Cannot find integration settings, creating default settings");
instance = CreateInstance<Settings>();
instance.name = "FMOD Studio Integration Settings";
instance.CurrentVersion = FMOD.VERSION.number;
instance.LastEventReferenceScanVersion = FMOD.VERSION.number;
#if UNITY_EDITOR
if (editorSettings != null)
{
editorSettings.CreateSettingsAsset(SettingsAssetName);
}
else
{
// editorSettings is populated via the static constructor of FMODUnity.EditorSettings when in the Unity editor.
RuntimeUtils.DebugLogError("[FMOD] Attempted to instantiate Settings before EditorSettings was populated. " +
"Ensure that Settings.Instance is not being called from an InitializeOnLoad method or class.");
}
#endif
}
isInitializing = false;
}
}