System::setOutput after Studio::System::initialize

Unity
1

I know the title is a duplicate of this: https://www.fmod.org/questions/question/systemsetoutput-after-studiosysteminitialize/

But I’m having a new special problem with the setOutput function. As Mathew Block states in the link, on windows you can change output mode after system::initialize. However, it does not seem to work properly. If I keep my default (FMOD_OUTPUTTYPE_WASAPI) output mode and then swap to FMOD_OUTPUTTYPE_NOSOUND_NRT after initialize. The “NRT”, non-realtime, part does not apply. My sound disappears, but it’s still in real time.

If I do it the other way around, set output mode to FMOD_OUTPUTTYPE_NOSOUND_NRT before initialize and then swap to FMOD_OUTPUTTYPE_WASAPI after initialize, the sound start playing, but it’s till in non-realtime mode. So it seems that you can change output mode after initialize (the getOutput even gives you the value you passed). But it will be locked to “non-realtime” or “realtime” respectively depending on what you chose before initialize.

I’m using 1.08.11, but I’ve looked though the change log of newer version and not found any related fix.
So is this a bug or I’m I using it wrong?

I use “raw” FMOD via the C# wrapper in Unity if that matters.

Thanks in advance!

2

Hi Mikael, thanks for your report. I’ve logged this issue as a bug and we’ll fix it in a future version. Cheers.

1 Like
3

Would you possibly have any ETA on this? I’m working on trying to restart the whole runtime while the game is running as a workaround, but it’s not working out too well, so to have this fixed would be really preferable!

4

We don’t have an estimate just yet as it still requires some time to investigate.

5

Hi Mikael

After investigating this issue we’ve determined that we can’t readily support switching between realtime outputs and the NRT output types (FMOD_OUTPUTTYPE_WAVWRITER_NRT, FMOD_OUTPUTTYPE_NOSOUND_NRT) when using the FMOD Studio API.

The reason is that when the FMOD Studio system is initialized with an NRT output the system is forced into synchronous update mode. Once the system is in synchronous update mode it cannot be dynamically switched to asynchronous update mode. Similarly if the system is in the default asynchronous update mode it cannot later switch to synchronous update mode.

This does present a workaround for your case though - if you initialize the system in synchronous update mode by passing the FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE flag then you will be able to switch freely between realtime and non-realtime outputs.