Fast FMOD Bank Loading Redux

[maddie480]

Reapply #1079 + apply fixes from #1103

[maddie480]

even though #1079 and #1103 were approved, I'm not merging this because I heard there were other issues with fast FMOD bank loading, not sure what though

[Wartori54]

The bug-hunt status of the Fast FMOD Loading currently is:

• Possible deadlock due to accesses to the Content map in the main thread, while audio is being loaded in parallel. (Fixed in what was potentially fix freeze with fast FMOD bank loading #1103 and in this PR.)
• Duplicated GUIDs in banks can cause load order issues, where, if the same GUID is associated with multiple (and different) paths, the IngestBank call order matters. (There may be extra issues inside of FMOD itself for when a GUID is also duplicated in the .bank file as well, this is yet to be investigated.)

[wuke32767]

my theory was,

in old sequential load, it's:

load A.bank -> ingest A.guids.txt -> load B.bank -> ingest B.guids.txt -> ...

in new async load, there's one of the possibilities:

load A.bank -> load B.bank -> ingest A.guids.txt -> ingest B.guids.txt -> ...

the difference is,

Everest/Celeste.Mod.mm/Patches/Audio.cs

Lines 223 to 228 in 985fd82

	if (!Guid.TryParse(line[..indexOfSpace], out Guid id) || cachedPaths.ContainsKey(id))
	continue;
	// only ingest the GUID if the corresponding event exists.
	if (system.getEventByID(id, out EventDescription _event) > RESULT.OK)
	continue;

if A.guids.txt and B.guids.txt both declared an path<->guid whose corresponding event is only defined in B.bank,

in old sequential load, A.guids.txt is filtered out because only ingest the GUID if the corresponding event exists. it is not loaded so does not exists.

in new async load, A.guids.txt is applied. then B.guids.txt is filtered out because the given ID is already registered.

if unfortunately A.guids.txt is wrong, it breaks.

---

i made two branches to bypass it. any of them can work, but which one is better?

wuke32767@10b9bb5

this branch allows multiple paths to be mapped to the same guid.
side effect:

• guid will only be mapped to the first path.
• some event paths which is originally filtered out will be available again.
• there might be multiple different eventdescription with the same guid becomes accessible.

wuke32767@d6bb3ee

in this branch, guid<->path in A.guids.txt is only registered when it's defined in A.bank.
side effect:

• will someone rely on it? like make multiple bank and only put one guid here?

[DashingCat]

Thanks @wuke32767 for looking into the issues related to Fast FMOD Bank Loading.

About your two suggestions, I believe the second approach is better, because I think we can reasonably expect GUIDs to be defined in the related bank. If this assumption does not hold in practice, we could still fallback to the first approach.