FMOD.System.getDriver is unreliable after the default device is changed on Windows

I just ran into the same issue…

In my case I am using the FMOD_SYSTEM_CALLBACK_DEVICELISTCHANGED override and had previously called SetDriver, so my initial configuration is:

  • 0: Device A = System
  • 1: Device B
  • 2: Device C = Output
    A call to System::getDriver yields 2.

Next, I switch the system device from A to C, so the new configuration is:

  • 0: Device C = System, Output
  • 1: Device A
  • 2: Device B
    A call to System::getDriver STILL yields 2, so it is incorrect under any interpretation.

WORKAROUND: Do not use getDriver.
According to the specification, the output driver switches with the system driver IFF a callback is NOT registered for FMOD_SYSTEM_CALLBACK_DEVICELISTCHANGED. So, register the callback, cache the driver GUID, and check each device to see if the previously active device is still connected.

WARNING: When I tried to enumerate connected devices in the callback I caused Unity to deadlock. Instead, use the callback to flag that an update is needed, then update on Unity’s main thread. See: BUG: Unity Editor hangs when handling DEVICELISTCHANGED callback - #2 by Reification