getSoundInfo / createSound on main thread? Or no

[VoodooDetective]

I wrote a small wrapper around FMOD for Unity to help me load dialogue among other things.

Here’s the main function for loading dialogue using programmer instruments.

I was wondering if what I’m doing there on the main thread is OK, or if that is better relegated to the FMODNativeCallback handler I wrote.

I don’t know if CreateSound or GetSoundInfo happen synchronously or not so I wanted to figure out if those need to move to the callback handler.

[li_fmod]

Hi,

Thank you for sharing the information.

@VoodooDetective

I was wondering if what I’m doing there on the main thread is OK, or if that is better relegated to the FMODNativeCallback handler I wrote.

I don’t know if CreateSound or GetSoundInfo happen synchronously or not so I wanted to figure out if those need to move to the callback handler.

If you’re using FMOD_NONBLOCKING with System::createSound, it’s fine on the main thread since the load happens asynchronously.

Studio::System::getSoundInfo is synchronous but usually lightweight, so it’s also okay unless you’re calling it frequently.

That said, moving both to the FMOD_STUDIO_EVENT_CALLBACK_CREATE_PROGRAMMER_SOUND callback is the safest approach for performance and thread safety.

Hope this helps, let me know if you have questions.

[VoodooDetective]

@li_fmod Thanks so much for the explanation.

But it seems like, if you use NONBLOCKING, then it’s not possible to produce a loaded FMOD.Sound to set in FMOD.Studio.PROGRAMMER_SOUND_PROPERTIES.

If you wait until the NONBLOCKING callback fires, then it’s already too late to set the PROGRAMMER_SOUND_PROPERTIES.sound value because it’s expected to be set synchronously in the FMOD.Studio.EVENT_CALLBACK callback.

So, it seems like you actually MUST load the Sound on the main thread (using coroutines or Tasks).

Am I missing something?

[li_fmod]

@VoodooDetective

But it seems like, if you use NONBLOCKING, then it’s not possible to produce a loaded FMOD.Sound to set in FMOD.Studio.PROGRAMMER_SOUND_PROPERTIES.

If you wait until the NONBLOCKING callback fires, then it’s already too late to set the PROGRAMMER_SOUND_PROPERTIES.sound value because it’s expected to be set synchronously in the FMOD.Studio.EVENT_CALLBACK callback.

Apologies for the confusion.

Have you had a chance to look at our Unity Programmer Sounds example?

In the FMOD_STUDIO_EVENT_CALLBACK_CREATE_PROGRAMMER_SOUND callback, you only need to assign a valid FMOD.Sound handle to PROGRAMMER_SOUND_PROPERTIES.

The sample data behind that handle can still be loading (e.g. if you created it with NONBLOCKING) as the mixer will wait a short window and then start as soon as the data arrives.

For more information, you could have a look at Non-blocking Sound Creation.

[VoodooDetective]

Thanks for the response, @li_fmod!

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().

So I think the Programmer Sounds example is not code that will always work. The problem seems to occur more frequently when dealing with audio tables.

The only options we actually have are:

1. Make sure the sound is OPEN before CREATE_PROGRAMMER_SOUND is called. This would suggest you have to create the Sound outside of the native callback.
2. Go ahead and create the Sound in the native callback, but register a callback for NONBLOCKING and somehow route that callback back up into the main thread so that we know when it’s safe to hit Start().

The version in the example code is not a viable option unless I’m missing something big.

[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.

[li_fmod]

@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().

So I think the Programmer Sounds example is not code that will always work. The problem seems to occur more frequently when dealing with audio tables.

Apologies, I have tested our Programmer Sounds example with a long compressed asset (10 minutes, ~20MB) loaded using FMOD_CREATESAMPLE | FMOD_NONBLOCKING, and I was able to play the sound as expected. I didn’t encounter the issue you described.

Could you please share a code snippet of how you are setting up and starting the event? I’d like to confirm if there’s any difference in how we are handling the sound.

Also, would it be possible to upload a minimal reproduction project to your FMOD profile? That would help me take a closer look and better understand what might be going wrong in your case.

[VoodooDetective]

@li_fmod

n allows for it, preloading the required sounds on the main thread before triggering the event could be an effective strategy.

Thanks for checking it out! That’s interesting. I’ve been testing with Audio Tables specifically and been able to reproduce the issue consistently. I could try to provide an example if that’d be helpful.
ShortSleeveStudio/FMODHelpers at repro

Please download this example project and hit play. Spacebar will play the sound and you’ll see the console fill with warnings. Note: this is code copied verbatim from the example documentation.

Here are some example warnings:

[FMOD] SoundSourceInstrumentInstance::startChannelIfReady : Loading delay exceeded, sound may play at incorrect time
[FMOD] SoundSourceInstrumentInstance::startChannelIfReady : Loading delay exceeded, sound may play at incorrect time

It’s hard to tell here, but the first warning actually has more whitespace before the word “loading”. I don’t know if that has any significance.

@li_fmod

[li_fmod]

Thank you for sharing the error messages and repro.

@VoodooDetective

Please download this example project and hit play. Spacebar will play the sound and you’ll see the console fill with warnings. Note: this is code copied verbatim from the example documentation.

Here are some example warnings:

[FMOD] SoundSourceInstrumentInstance::startChannelIfReady : Loading delay exceeded, sound may play at incorrect time
[FMOD] SoundSourceInstrumentInstance::startChannelIfReady : Loading delay exceeded, sound may play at incorrect time

You could try setting the sound mode to FMOD.MODE.CREATESTREAM, which should help avoiding the warning messages.

There’s also a helpful discussion on this topic here:

Example code for Programmer Instruments doesn't work. "Loading Delay Exceeded"

Hi, The Loading delay exceeded, sound may play at incorrect time error means that too many samples are being loaded in at once, to solve this we need to change which FMOD.MODE we use when creating the sound. The line we will need to change is: FMOD.MODE soundMode = FMOD.MODE.LOOP_NORMAL | FMOD.MODE.CREATECOMPRESSEDSAMPLE | FMOD.MODE.NONBLOCKING; //Too FMOD.MODE soundMode = FMOD.MODE.CREATESTREAM; In the CALLBACK function. This mode is explained under FMOD API Reference | Common | FMOD_MODE…

@VoodooDetective

It’s hard to tell here, but the first warning actually has more whitespace before the word “loading”. I don’t know if that has any significance.

I did notice the extra whitespace you mentioned in your reproduction project.

However, I wasn’t able to reproduce the warning messages on my end with a similar setup.
Is it possible that some parts of the original example code were unintentionally modified during integration?

[VoodooDetective]

Hi @li_fmod! Thanks once again for taking a look.

I’m a little confused, it sounds like you downloaded my code, but did NOT see the warnings I was seeing. Is that correct? Or did you have different code?

Mine is essentially a copy from the documentation (minus the if/else to load from a file instead of an audio table) which I would expect to work out of the box without warning. Are you not seeing these warning?

But also, I just realized, while the warning messages coming by default from the documentation’s example code is, I think, a problem, this isn’t actually the issue I was seeing when I made my original post. I’m going to have to go back and find a better code example of that because it was more than a warning message. Sorry for the confusion!

[li_fmod]

@VoodooDetective

I’m a little confused, it sounds like you downloaded my code, but did NOT see the warnings I was seeing. Is that correct? Or did you have different code?

Mine is essentially a copy from the documentation (minus the if/else to load from a file instead of an audio table) which I would expect to work out of the box without warning. Are you not seeing these warning?

Sorry for the confusion. What I meant is that I did open your project and I did see the warnings you’re referring to.

However, I wasn’t able to reproduce any additional warnings beyond the usual delay exceeded messages. Specifically, I didn’t encounter the extra whitespace related warnings form your project when testing with an empty project.