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 .()
…
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
Don’t have that kind of stack trace 
I mean, the exception throw happens in c# wrapper… it doesn’t actually crash in internal libs.
I am really sorry, but without more information, I don’t know how to assist further.
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)
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.
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.
Hi everyone, I saw this post, and although I experienced the exact same error on a PC game via Steam, and it wouldn’t load past the startup screen, I did manage to troubleshoot it and figured it out. I know this thread is about Android devices, but still, perhaps it could apply to them?
I have a FiiO K3 DAC, which is connected via USB to pc, and 3.5 jack to headphones.
In the Windows settings, to get best audio fidelity, I have the sample rate and bit depth at maximum, which is 32 bit, 384000 Hz.
With some tests, I found out that the game couldn’t run when the sample rate is above 192 kHz, at any bit depth. When it was set to 192 kHz or below, it ran fine.After some research, I found out that FMOD does have an upper limit, and the error either causes the game to be silent, or not run.
Hopefully this info will help anyone with a similar error, since it’s quite random, due to some very specific computer settings.
Behavior will depend on how the game is using FMOD here. The default behavior is to run FMOD at the rate the game designates and resample from that rate to the rate the output device requires. Some games tell FMOD to run at the rate the output device is configured for, this can be good at avoid a bit of latency from the resampler but can be bad if the device runs at extreme rates. Internally we limit the maximum rate to 192 kHz, so I suspect that was the issue you encountered, and the game code didn’t handle that gracefully. Running games at such high rates is almost never a good idea though since most game content is authored at 48 kHz, so those assets will be resampled up to 384 kHz putting a lot of extra demands on the game for no improvement in quality.
Yeah, that’s perfectly understandable, only insane people would set their Windows bit depth and sample rate to the utmost max, like me.
Since it was such a random convergence of events preventing the game from loading, and the solution was something as quirky as reducing the sample rate for your audio device, I just felt that I should post about it on the forum, as some people do use DACs on their PCs, and could experience the same problem.
FYI, I also posted the same solution for the game in the bug reports on their Steam Community page, for the same reason, to help others.
Cheers, thanks for the report, it’s always good to leave a paper trail for things like this so future generations can find it and gain understanding.