my game (with custom engine) uses the fmod library (v2.02.07) for audio output. Few problems so far which is great!
However, when I unplug my headphones (connected via headphone jack, not USB or bluetooth) during gameplay on macOS, my app crashes with the following console output:
HAL_HardwarePlugIn_DeviceStart: no device
HALPlugIn::StopIOProc: got an error from the plug-in routine, Error: 560947818 (!obj)
Now, I am not sure if fmod is to blame here or some underlying macOS API but the problem is strictly reproducible and only occurs when unplugging the headphones from my machine, not when plugging it in during gameplay.
Do you have any FMOD logs that we could have a look at? If not, you can enable FMOD Logging by including the fmodL.dll and the fmodL_vc.lib. Included in the FMOD Engine directory under FMOD Studio API Windows/api/core/lib/x(the system you are using). Including those in your project, you will then need to initialize the debug system. You will call FMOD_Debug_Initialize(FMOD_DEBUG_LEVEL_LOG, FMOD_DEBUG_MODE_FILE, 0, "FILE NAME"). This will output all FMOD calls to a log file. If you could upload that log file it will help resolve the issue.
I guess it doesn’t show anything unusual (the crash did happen but did not produce any visible FMOD log output) so I suspect the issue is outside of FMOD? I can also not reproduce the problem on Windows.
Thanks for sharing the log, I cannot see anything in there to indicate this failure is coming from FMOD.
It might be worth seeing if you still get the crash after disabling the default device switching behaviour. You can do this by setting an FMOD_SYSTEM_CALLBACK on FMOD_SYSTEM_CALLBACK_DEVICELISTCHANGED or FMOD_SYSTEM_CALLBACK_ALL and just returning FMOD_OK, e.g
Please give that a shot and let me know the outcome. If it doesn’t crash then you might be able to implement your own switching behaviour inside that callback to workaround the issue. Otherwise I have not been able to reproduce this- are you on the latest MacOS?
Thanks Jeff for the hints. I tried what you suggested. The crash still happens and the FMOD log output stays the same. What I do get is a slightly different general output:
AudioObjectGetPropertyData: no object with given ID 78
AudioObjectRemovePropertyListener: no object with given ID 78
Interestingly, when the crash happens, the stack is (reproducibly) residing in my Metal backend code which I find somewhat curious.