How to use DynamicSoundGroupCreator Asynchronously

Thanks for the help. Unfortunately, that didn't fix it. What is causing the spike is the process of duplicating the sound groups from DynamicSoundGroupCreator to MasterAudio when DSGC is enabled. I'm going to try to take apart DynamicSoundGroupCreator.CreateItems and put it in a coroutine to spread the duplication process to a few frames. Hopefully that should do it.

Since I have "Load In Background" checked for the audio files, they don't seem to be the cause. I disabled auto-create items and triggered it manually at a later time and triggering it what caused the spike (AddComponent taking the most time).

You are right, coroutines do generate small garbage but since I'm doing it once, it should be insignificant.

I'll let you know how it goes.

Having the option to doing a "move X per frame" would be great! There is close to 50 sounds in my DSGC and I'm running this on PC.

I understand that the sounds would not be available right away. But in my case, I would simply listen to the "Items Created" event to know when they are ready before proceeding to use them.

Thanks for looking into it!

Great! Thanks!

Hey, sorry for the Necro, but it's probably better to add to this thread rather than start a similar one

Originally, we had most of our sounds setup in MasterAudio but in an effort to reduce the ram useage of players, we swapped over to a `DynamicAudioGroupCreators` approach. Over time, this lead to a similar issue to the guy above, during loading screen, we were loading multiple DynamicAudioGroupCreators (typically 2) with ~90 DynamicSoundGroup each, each with multiple (3-20+) DynamicGroupVariations. At worst case by loading them all sync using the built in DynamicAudioGroupCreator we were look at around 1100ms (https://cdn.discordapp.com/attachments/480345368056561664/831917188595449926/unknown.png). We've tried doing a load them async over multiple frames, but the sheer number of assets that ended up having to be loading like this, easily took 5-10 second which was quite ugly.

Narrowing this down, we found the main culprit to be the "mirroring" of DynamicSoundGroup->MasterAudioGroup and DynamicGroupVariation->SoundGroupVariation conversions. As such we ended up retooling MasterAudio a bit which might be helpful to other's, and maybe it could be implemented into base MasterAudio.


What worked for us was the following:
Pre-generation/editor
- We wrote a simple editor tool extension which creates the `MasterAudioGroups` in the `MasterAudio` that is central in our game (similar to the DynamicAudioGroupCreator)
- We moved these MasterAudioGroups to a different asset location which we could load back in at runtime from somewhere else (in our case, we have a per-voice actor scene and async load this)
- We pre-generated and stored the `AudioInfo` and `playedStatuses list` so we don't have to generate these everytime we need them at runtime

Runtime
- Load these presets somehow
- We reparented them under the MasterAudio prefab
- We extracted the last part of `MasterAudio.CreateSoundGroup` which is being used by the `DynamicAudioGroupCreator` to load these `MasterAudioGroups` to MasterAudio, specifically the RuntimeGroupInfo, Randomizer and Leftovers sections.
- To unload we found the `MasterAudio.DeleteSoundGroup(name)` method which worked right out of the box.

Hope its clear enough and it might help someone else;