getSoundInfo / createSound on main thread? Or no

[li_fmod]

Thank you for sharing your insights and solutions!

@VoodooDetective

Actually, I think you have to wait until the Sound is in the OPEN state before you can call Start() on the event.

That being the case, you can’t actually hand a Sound that isn’t open to the Event otherwise you won’t know when it’s OK to hit Start().

You way of monitoring the sound’s open state using Sound::getOpenState and delaying the CREATE_PROGRAMMER_SOUND call until the sound is ready sounds like a solid approach to ensure that playback begins only when the sound data is fully available.

Alternatively, if your projects design allows for it, preloading the required sounds on the main thread before triggering the event could be an effective strategy.

I also found a similar discussion here that might relevant to your case:

Delay exceeded warning when using Programmer Instrument and Audio Table

This warning just means it took a little longer to load the sound, it shouldn’t cause any noticeable issues unless you need extreme precision of the sound’s start time. If timing is crucial for you, you can move the System::createSound part out of the callback and into a coroutine to preload it at an earlier stage. Then, instead of passing a string handle into your callback you can give it a handle to your preloaded sound.