Hard crash in build when using Audio Random Container (ARC)

Audio & Video
, ,
1

We are running into a crash when trying to play back ARC assets but only in build and only, so far, on one of the target platforms (Nintendo Switch). From the crash dumps it looks like the audio resource is being double freed but I can’t see anything in the game logic that would cause that kind of behaviour. The call stack seems to be entirely from the internal audio module loop.

Is this a known issue on some platforms, or is there a possible cause that could be worked around as I am looking for any quick solutions before replacing ARC entirely with a custom solution.

2

We have not seen any hard crashes with our internal testing, would be great to either get a minimal reproduction through a bug report, if not possible some info on your setup would be great - number of ARC’s, clip lengths, number of clips, number of audio sources etc.

3

I’ve been trying to reproduce it in a smaller project but haven’t had any luck. I did track down a reproducible case in the full project that does speak to something the game may be doing to get into a weird state but nothing is jumping out at me.

The game hard crashes when the audio source is being paused.

The setup is a prefab with multiple audio sources on children, each with a reference to an audio random container asset. The ARCs are primarily used as playlists in this use case, with each ARC holding a list of audio clips to play sequentially. In practice, only one of the ARCs has multiple clips within it. At runtime, the prefab lives in DontDestroyOnLoad nested inside another parent prefab that is a singleton.

The purpose is to crossfade music when moving between scenes. The issue occurs when leaving the main area of the game and its music fades out.

High level flow of logic:

  • The script on the prefab with references to all the audio sources subscribes to SceneManager.sceneLoaded in OnEnable.
  • When the sceneLoaded event is raised, the next scene is checked against a list and, if there is a match, a cross fade between audio sources happens between the current and next appropriate audio source
  • The next audio source has Play called on it
  • The old audio fades out while the new audio fades in
  • At the end of fading out, the audio source is either paused or stopped
    • If the scene is not the main scene, the audioSource is stopped
    • If the scene is the main scene, the audioSource is paused so that it’s position in the playlist can be preserved
  • The game crashes in the audio update after the call to pause
  • The game does not get this crash if the audioSource is stopped

The fades are handled by DOTween in this case, but the crash happens even if Pause is called immediately, with DOTween entirely removed, so I do not have reason to believe the fading itself or mechanism for fading out is related.

The call stack from the crash dump with references to closed platforms removed:

AudioRandomContainerRuntime::CleanUpFinishedClipPlayables() Line 321 (0x1D369E0CFC)|C++
AudioRandomContainerRuntime::Update() Line 544 (0x1D369E2FB4)|C++|
AudioManager::Update() Line 2651 (0x1D36A0888C)|C++|
AudioModule::Update() Line 34 (0x1D369D0B1C)|C++|
ExecutePlayerLoop(NativePlayerLoopSystem* system) Line 409 (0x1D3627B934)|C++|
ExecutePlayerLoop(NativePlayerLoopSystem* system) Line 430 (0x1D3627B978)|C++|
PlayerLoop() Line 537 (0x1D3627BBE8)|C++|
Main() Line 690 (0x1D3677568C)|C++|

and the native exception

 0x00000002:  Access Violation of Data

I can confirm that the clip that is being cleaned up in the stack frame is one from the main are’s ARC, based on the length of the clip as visible in local variables. And, as mentioned, changing Pause to Stop prevents the crash entirely.

I’ll continue to try and get this reproducing in a smaller project to share, though my focus now is to replace the use of ARC on the main music playback with a simple playlist component to get things moving with the development team.

4

This is good information, thanks, ill try writing some tests that do similar things and see if I can get a fail. If you can slim down the main project and still get a reproduction we would also accept that in the bug report, if thats something you are able/willing to share with us, no worries if not.

Also what version are you on?

5

The project is running on Unity 6000.0.67.

I just wrapped up converting the one case where it crashes to avoid ARC and the Playables API which seems to resolve it in build. I have a few other high priority tasks to get through but I’ll talk to the team about creating a bug report with a slimmed down version of the game with any closed platform development removed once things are stable.

6

Hello,

Having the same crash on Unity 6000.3.11f1. The game only crashes on Android builds, the crash happens when the audio source is stopped.

We noticed, that changing Audio clip “Load Type” to “Streaming” causes the crash, other load types doesn’t. Used “Vorbis” compression format.

image
image993×417 31.7 KB

7

@hvalenta Thanks for mentioning AudioClip Load Type, I had not poked into that with my testing before. Sure enough writing some tests that immediately (literally 1 frame) pause an ARC playing a streaming clip on less powerful devices can provoke the crash. It seems to be a fairly simple fix, follow the progress of the bug here Unity Issue Tracker - ARC crash when pausing AudioSource with streaming clips on slower devices (Switch/Android)

Thanks both for flagging this!

8

Thank you! I was actually in the middle of doing a full replacement when you posted because the crashing had returned. Saved me a ton of time and potential bugs. QA just confirmed changing the load type resolved the crash.

@hvalenta Great news! Apologies for not getting a repro sooner but the streaming load type makes sense as QA had reported the crash happened more often if logging to file was enabled, which slows down performance and keeps IO busy. Thanks for looking into the issue.