[Unity] Setting the current driver to the current OS audio output

Unity
1

Our integration of FMOD into Unity has been pretty seamless, but we had noticed that any change to the operating system’s current audio output will not be reflected in FMOD audio if changed during runtime. This behaviour is different to native Unity audio, which will switch drivers as the OS audio output is changed. I am to understand this is intentional, as mentioned in this related post.

I can manually manage driver switching through the FMOD.System.getDriver()/setDriver() methods. Additionally, Unity provides the AudioSettings.OnAudioConfigurationChanged event that can be observed.

Using these methods and event, I could resolve this if I can determine which driver I should switch to. Is there a way to determine the current OS audio output/default Unity audio output? Or is there any simpler implementation to achieve this?

For context, it is advised that our VR game requires our audio to match the OS audio output to pass submission for the Oculus Store.

2

We haven’t come across this requirement from Oculus previously.

I’m not sure if there is a way to query the current output device from Unity, but there is a way you can work around this on Windows.

Using the event provided by Unity, you can call System.setOutput(FMOD_OUTPUTTYPE_AUTODETECT) (or the output mode you wish to use), this will reset the current enumeration list of devices, then you can call System.setDriver(0) as zero is always the current default.

Because of backwards compatibility with Windows XP the API we were using could not tell us when the default changed. We do have a task in our system to change this behavior, although I cannot give any kind of time frame for it at the moment.

3

Thank you @cameron-fmod, this was exactly what we needed.

For further context:

  1. Our transition to FMOD still has some legacy audio via PhysSound using Unity’s audio output, which will output to the default source if changed. It was more suitable for us to redirect all audio in this case, rather than only parts of the game audio. Also, this feels like something we’d use across any projects regardless, as switching OS audio output during runtime doesn’t feel overly uncommon.

  2. Oculus’ offline VRC Validator used for testing prior to a submission was regarding this as a failed test, but during the technical build review this did not present a problem (and we have observed other Oculus Store titles that also do not switch the audio output during runtime). This was a misunderstanding on our part with some inconsistencies between the validator and the actual submission process.

Thanks again.