[FMOD] Initialization failed : Output forced to NO SOUND mode : ERR_INTERNAL : An error occurred that wasn't supposed to. Contact support

FMOD Engine
,
21

Stack trace is there, it happens on startup, on first access to the runtime manager (lazy init):

Unknown:-1 FMODUnity.RuntimeManager.get_Instance .()
Unknown:-1
FMODUnity.RuntimeManager.get_StudioSystem .()
Unknown:-1
FMODUnity.RuntimeManager.GetBus .(System.String path)
Unknown:-1
xxx.MusicManager.InstantiateBuses .()
…

22

Looking for a stack trace that looks more like this:

libaudioclient.so    0x49a98244 + 606788
libaudioclient.so    0x49a98238 + 606776
libaaudio_internal.so    0x94b59b74 + 183156
libaaudio_internal.so    0x94b4aa10 + 121360
libaudioclient.so    0x49ab9ab0 + 744112
libaudioclient.so    0x49a47a08 + 277000
libbinder.so    0x33393880 + 301184
libbinder.so    0x3339d910 + 342288
libbinder.so    0x3339d42c + 341036
libbinder.so    0x3339dcdc + 343260
libbinder.so    0x333ca418 + 525336
libutils.so    0x49be058c + 79244
libandroid_runtime.so    0x31ef34b8 + 783544
libutils.so    0x49bdfde8 + 77288
libc.so    0x313cbd44 + 986436
23

Don’t have that kind of stack trace :slight_smile:

I mean, the exception throw happens in c# wrapper… it doesn’t actually crash in internal libs.

24

I am really sorry, but without more information, I don’t know how to assist further.

25

So this is an issue in FMOD Unity Package. Basically FMOD doesn’t crash in libfmod or libfmodstudio. The crash happens because the unity package handles failed initialisation with an exception:

Here is the code from package that causes the crash:

 if (initResult != FMOD.RESULT.OK) {
                        throw new SystemNotInitializedException(initResult, "Output forced to NO SOUND mode");
                    }

And it happens because of this:

  result = studioSystem.initialize(virtualChannels, studioInitFlags, FMOD.INITFLAGS.NORMAL, IntPtr.Zero);
            if (result != FMOD.RESULT.OK && initResult == FMOD.RESULT.OK) {
                initResult = result; // Save this to throw at the end (we'll attempt NO SOUND to shield ourselves from unexpected device failures)
                outputType = FMOD.OUTPUTTYPE.NOSOUND;
                RuntimeUtils.DebugLogErrorFormat("[FMOD] Studio::System::initialize returned {0}, defaulting to no-sound mode.", result.ToString());

                goto retry;
            }

Shouldn’t this be handled differently? A softer way would be better… either without sound… or try to reacquire audio a bit later (If I remember correctly on Android, you have to sometimes retry to aquire audio, because someone else could be holding the audio resources)

1 Like
26

Hi,

Yes, we could certainly handle this in a less destructive way. Thank you for looking into this I will pass your findings on to our development team to look into further.

27

I’ve reviewed this issue and I can appreciate the difficulties of devices in the wild malfunctioning. Ideally, we’d love to fix the core issue, however, without either you or us being about to reproduce it, the chances of a fix are very slim.

I agree with your assessment of the no-sound fallback needing to be softer. When it was originally developed the idea was to throw a single exception on first access of the runtime manager. That way the issue was raised, then subsequent access of the runtime manager would succeed (in no-sound) allowing the application to continue. However, if that first call stack is critical to your application initialization, the exception will terminate it making the problem unrecoverable. If you have an exception reporter set up, this will log once per game, which may or may not be useful. Also, if you intercept exceptions and terminate the game, then this behavior is a deal breaker.

The simplest fix is to remove the exception, you can do this yourself by commenting out or removing throw new SystemNotInitializedException(initResult, "Output forced to NO SOUND mode") from private static RuntimeManager Instance in RuntimeManager.cs. This should give you the softer behavior you desire and is inline with the change we are planning to make in a future release.

This change will reduce the visibility of the initialization failure and increase instances of your users reporting the game running as silent. The result is still undesirable, but perhaps less bad. To reiterate, we still want to fix this core issue your users are seeing to solve this for good, so if you manage to reproduce it or get some more clues, please pass them on.

1 Like