Search Unity

Audio FMOD Crashes With Async Load

Discussion in 'Audio & Video' started by Multithreaded_Games, Jan 10, 2018.

  1. Multithreaded_Games

    Multithreaded_Games

    Joined:
    Jul 6, 2015
    Posts:
    121
    Ran into a rather unfortunate, but devastating problem that I'm hoping someone can shed some light on. The main gist is as such: We have two main scenes and a loading scene. Whenever the player transitions to the next scene, we move them into a loading scene while the next scene asynchronously loads--pretty standard stuff, right?

    In order to have music continue playing all the while, the AudioSource component is attached to our GameManager object, which is marked as DontDisableOnLoad (or whatever it's called), thus it persists between all scenes. However, every 1 in 100 or so transitions, Unity inexplicably crashes--interestingly, the actual AudioSource's clip is NEVER changed during this time--it always plays the same song on a loop. However, as we don't use a persistent camera (the camera belongs to each loaded scene, including the loading screen itself), the AudioListener changes each time a transition is encountered. Also, the Audiosource's clip is set to loop.

    Even more interesting is that it never crashes on the LoadingScreen itself--it's always one of the two 'main game' scenes that seems to crash before being fully loaded. As you can imagine, this is an incredibly frustrating bug that seems to have no obvious cause--I can confirm though, however, that it does not happen when the loading screen is not used. Let me repeat: when LoadLevelAsync is not called/used, there is never a crash. Frustratingly, it also never happens during Debug mode. I know this because I set up a test to force the player character to repeatedly move between the scenes. This runs over night and crashes, without fail, within 100 iterations or so, but when asynchronous scene loading isn't used/Debug Mode is enabled, it's still running in the morning, after some 20k iterations.

    Again, I'd love to provide a repro project, but it'd be incredibly difficult at this point, given the maturity and complexity of our project. Mainly just posting this to see if anyone can throw out any leads. With debug symbols enabled, this is the stack trace I get when it crashes:

    ========== OUTPUTING STACK TRACE ==================

    0x00007FFB7E729B71 (UnityPlayer) FMOD::Codec::read
    0x00007FFB7E7226A3 (UnityPlayer) FMOD::CodecFSB5::readInternal
    0x00007FFB7E729B71 (UnityPlayer) FMOD::Codec::read
    0x00007FFB7E6DCCC5 (UnityPlayer) FMOD::SoundI::readData
    0x00007FFB7E6DB6F1 (UnityPlayer) FMOD::SoundI::read
    0x00007FFB7E6C80AE (UnityPlayer) FMOD::SystemI::createSoundInternal
    0x00007FFB7E6C9301 (UnityPlayer) FMOD::SystemI::createSound
    0x00007FFB7E6B3783 (UnityPlayer) FMOD::System::createSound
    0x00007FFB7E0E3677 (UnityPlayer) LoadFMODSound
    0x00007FFB7E0B57C9 (UnityPlayer) AudioClip::AwakeFromLoadThreaded
    0x00007FFB7DD734F6 (UnityPlayer) PersistentManager::postReadActivationQueue
    0x00007FFB7DD79B9F (UnityPlayer) PersistentManager::LoadObjectsThreaded
    0x00007FFB7DC3DD49 (UnityPlayer) LoadSceneOperation::perform
    0x00007FFB7DC3D1C1 (UnityPlayer) PreloadManager::Run
    0x00007FFB7DC3D4C9 (UnityPlayer) PreloadManager::Run
    0x00007FFB7DC999F8 (UnityPlayer) Thread::RunThreadWrapper
    0x00007FFBBA042774 (KERNEL32) BaseThreadInitThunk
    0x00007FFBBC7E0D51 (ntdll) RtlUserThreadStart

    ========== END OF STACKTRACE ===========

    I've also attached the crash.dmp (note that I had to change the extension to a text file) file and an error file as well--the only DLL implicated is x_input1_3, which... isn't super helpful. I can also confirm that this happens on more than one machine.

    Also, OS is Windows 10, Unity version is 2017.2.

    At wit's end here, can any audio gurus shed any light on this? Thanks!
     

    Attached Files:

  2. Multithreaded_Games

    Multithreaded_Games

    Joined:
    Jul 6, 2015
    Posts:
    121
    Come on, guys... surely SOMEONE has seen this. For as common as a loading screen is, there is 0 chance that I am the only person in the world that has had this issue. I've tried so many things to alleviate this and it is incredibly frustrating to be at the mercy of yet another Unity quirk that has no apparent cause or reasoning.
     
  3. Ebonicus

    Ebonicus

    Joined:
    Oct 31, 2016
    Posts:
    82
    I have 5.4.5 project that works perfect.

    When upgrading to 2017.3 the loading screen using async load causes and Android Native crash on Moto g4 virtual machine devices on Google Play pre-launch testing.

    Crash can also be duplicated on our Google Nexus 1 and 2 tablets.

    You are not the only one. Here is my code that causes crash.

    Code (CSharp):
    1. //        if (loadingText != null) {
    2. //
    3. //            //Load scene with % displayed
    4. //            yield return new WaitForSeconds (SplashScreenTime);
    5. //            myOperation = SceneManager.LoadSceneAsync (sceneNumber, LoadSceneMode.Single);
    6. //
    7. //        } else {
    8. //
    9. //            //There is no text box, just load next scene
    10. //            yield return new WaitForSeconds (SplashScreenTime);
    11. //            SceneManager.LoadSceneAsync (sceneNumber, LoadSceneMode.Single);
    12. //      
    13. //        }
    Crash is NOT eliminated when I use this code:

    Code (CSharp):
    1. //        if (loadingText != null) {
    2. //
    3. //            //Load scene with no % displayed
    4. //            yield return new WaitForSeconds (SplashScreenTime);
    5. //            SceneManager.LoadScene (sceneNumber, LoadSceneMode.Single);
    6. //
    7. //        }

    Both code snippets are inside an enum function called LoadNextScene()

    If I remove the loading scene from my app, the crash disappears and app functions perfectly.

    I originally posted this as a crash Android Native, when I had no idea what it was. Unity asked me to submit bug report, I sent them complete app.

    Today I pinpointed the native crash to the loading scene.

    Nobody from Unity has answered my bug feedback to this day.

    There is something wrong with the SceneManager.LoadScene and SceneManager.LoadSceneAsync that is causing crashes.

    Unity please look into this and address the issue for 2017.3, please.
     
  4. Multithreaded_Games

    Multithreaded_Games

    Joined:
    Jul 6, 2015
    Posts:
    121
    Can confirm it's still present in 2017.4 as well. Also, thanks for replying--I really thought I was going insane here as there doesn't seem to be ANY mention of this bug anywhere. Maybe if we make enough noise, someone will notice?
     
  5. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    3,726
    That sounds like quite the nightmare. Based on this and your other experiences, would you guys advise against using FMOD, or do you still think it's worth it?

    Also have you contacted FMOD support directly in hopes that they have contacts at Unity that can expedite fixing this bug? After all it reflects poorly on their product even if it should be a fault within Unity.
     
  6. ycarowr

    ycarowr

    Joined:
    Dec 18, 2014
    Posts:
    5
    Does someone has a update about that issue? I'm having a stack trace very very similar. But still can't figure it out.
    Is it confirmed to be a unity bug?

    It has started in my project after I made some changes in the scene order:

    I use to have all my sounds being loaded within the first scene of the game. And in ANY other moment the player was allowed to go back to this first scene.

    Something like this: Scene_0 ----> Scene_1 (sounds loaded here) <--------> Scene_2

    However, I recently updated the game with a new "scene management" which allows the player to go back and forth in any scene. I also included a new Scene to be the first scene (which does not load the sounds).

    Such as: Scene_0 <------> Scene_1 (sounds loaded here) <------> Scene_2 <------> Scene_3
    (the player is allowed to go back to the first scene though any scene)

    I'm not using LoadAsync.
    And yes. SoundManager is a Singleton.
     
    Last edited: Jun 4, 2018
  7. KaliaAristidou

    KaliaAristidou

    Joined:
    Jun 30, 2017
    Posts:
    1
    We have also the exact same issue!! For some reason appears mainly on Android 8.0 (about 95% of the crashes) and is the number one crash right now that put the app in a position that violates Android vitals!! From 0.06% crash rate users we have 2.05% crash rate!
    Any ideas how to fix it??
     
  8. iileychen

    iileychen

    Joined:
    Oct 13, 2015
    Posts:
    66
    We got same issue here, very frustratingly. fmod_crash.png
     
  9. PieterAlbers

    PieterAlbers

    Joined:
    Dec 2, 2014
    Posts:
    109
    iileychen likes this.
  10. iileychen

    iileychen

    Joined:
    Oct 13, 2015
    Posts:
    66
    Thanks for the tips Pieter, i will give it a try to check whether it solve my issue.
     
  11. LawrenceDev

    LawrenceDev

    Joined:
    Aug 20, 2015
    Posts:
    20
    Hello, I'm having a FMOD error aswell, for me it says: FMOD failed to initialize. This may be because your sound card is configured to give applications exclusive access, thus preventing Unity from using this device. You can change this in Control Panel > Audio Devices and Sound Themes > Playback Device > Properties > Options ... : "Soundcard does not support the minimum features needed for this soundsystem (16bit stereo output). " (59)
    These are my settings:

    IDK if this is related to your issue, but I'm just letting you know you're not the only one with a FMOD error.
     
  12. iileychen

    iileychen

    Joined:
    Oct 13, 2015
    Posts:
    66
    This solved my problem, will not crash now if I clamp the pitch to max than 0.01f.
    Thanks Very Much!
     
    PieterAlbers likes this.
  13. PieterAlbers

    PieterAlbers

    Joined:
    Dec 2, 2014
    Posts:
    109
    Great to hear that it works for you!
    Just for the record - we were never having a negative pitch as it was always clamped to 0 zero before changing the min limit to 0.01. Still odd though...