Crash in recordStart when pulling USB device out in the same frame (OSX)

So QA has discovered that is you pull out the USB device (Focusrite 2i2, but don’t think that’s important), at the same time you switch mic recording to that device that FMOD will hard crash.

Observed Unity 2018.4.5f1, OSX 10.14.6, FMOD 1.10.16

This is very similar to Crash on Record Start on Mac mini Unity 2018.2.20 except is limited to pulling on (or perhaps very close to) the same frame.

We have tried all manner of:

  • StudioSystem.flushCommands()
  • LowlevelSystem.update()
  • LowlevelSystem.mixerSuspend() / LowlevelSystem.mixerResume()
  • frame-delays with coroutines

just prior to:

  • querying the current lowLevelSystem.getRecordDriverInfo() followed by
  • lowLevelSystem.recordStart(recordIdx, _micSound, true);

We have not found anything to indicate we are not good to make the recordStart(). The device is ALWAYS reported connected just prior to the call hard-crashing the system.

Like the previous poster we see:

[FMOD] OutputCoreAudio::recordStart : AudioObjectAddPropertyListener for kAudioDevicePropertyDeviceIsAlive returned 560947818.

UnityEngine.DebugLogHandler:Internal_Log(LogType, String, Object)
UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
UnityEngine.Logger:Log(LogType, Object)
FMODUnity.RuntimeManager:DEBUG_CALLBACK(DEBUG_FLAGS, StringWrapper, Int32, StringWrapper, StringWrapper) (at Assets/Plugins/FMOD/RuntimeManager.cs:29)
FMOD.System:FMOD5_System_RecordStart(IntPtr, Int32, IntPtr, Boolean)
FMOD.System:recordStart(Int32, Sound, Boolean) (at Assets/Plugins/FMOD/Wrapper/fmod.cs:2104)
FmodTest.<DoUpdateRecordIndex>d__41:MoveNext() (at Assets/Scripts/Mic.cs:361)
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) (at /Users/builduser/buildslave/unity/build/Runtime/Export/Coroutines.cs:17)

Which is then followed by a hard-crash:

Thread 0 Crashed:: tid_307  Dispatch queue:
0   libsystem_kernel.dylib        	0x00007fff7a4b92c6 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff7a574bf1 pthread_kill + 284
2   libsystem_c.dylib             	0x00007fff7a4236a6 abort + 127
3   com.unity3d.UnityEditor5.x    	0x0000000101053a21 HandleSignal(int, __siginfo*, void*) + 81
4   libmonobdwgc-2.0.dylib        	0x0000000142144331 mono_chain_signal + 79
5   libmonobdwgc-2.0.dylib        	0x0000000142015dcf mono_sigsegv_signal_handler + 414
6   libsystem_platform.dylib      	0x00007fff7a569b5d _sigtramp + 29
7   ???                           	000000000000000000 0 + 0
8   fmodstudioL                   	0x000000015d7742eb 0x15d58c000 + 1999595
9   fmodstudioL                   	0x000000015d771b39 0x15d58c000 + 1989433
10  fmodstudioL                   	0x000000015d79372e 0x15d58c000 + 2127662
11  fmodstudioL                   	0x000000015d78af76 FMOD::System::recordStart(int, FMOD::Sound*, bool) + 100

Is there anything we can do, to prevent this crash?



Thank you for reporting this, it does appear to be a bug.
I have raised this as a task but do not currently have a workaround for it.

1 Like

Cheers Cameron.

Look forward to hearing which release will contain the fix.



Hi Cameron

Is there an eta for getting this resolved? I’m due to roll off the project in around 6 weeks, and would like to leave the P2 bug depending on this closed.



The fix for this has already been added, although the next release is not due to go out until the start on January.

Excellent, thanks for the update. I presume this will be in 1.10.19?

Yes it will be in 1.10.19.