I’ve been contacted by a couple of users of Dissonance voice chat (a voice chat system for Unity) reporting that starting the microphone takes an extremely long time (over 1 second) if the “Oculus Virtual Audio Device” is in use.
One of these users is using Dissonance with the Unity Microphone system. In this case the Unity profiler shows this:
The highlighted line corresponds to calling the Unity Microphone.Start method (which is using FMOD internally).
I initially suspected that this was a Unity bug. However, another user is using our Dissonance for FMOD (Recording) package, which replaces the unity microphone with directly using FMOD. They report that when the “Oculus Virtual Audio Device” is in use starting up the mic takes over a second, exactly the same bug!
The highlighted line corresponds to this C# code:
// Start recording into the sound buffer
if (!Check(sys.recordStart(_deviceID, _sound, true), "Failed to call `recordStart`"))
return null;
Is this a known issue with FMOD and/or the Oculus Virtual Audio device? If so, if so is there a fix or a workaround?
I can’t see any known issue with using the Oculus Virtual Audio Device, and I am finding System.recordStart takes about 60ms to start with OpenSL and AAudio.
That said, I don’t see how using the Oculus Virtual Audio Device on Windows could affect recording on Android (VR), so I’m not sure I have set this up correctly. Can you please confirm the reproduction steps?
- On Windows, change output to “Oculus Virtual Audio Device”.
- Setup recording / use Dissonance etc and call
System.recordStart.
- Switch platform to Android and configure for VR.
- Select Run Device (in my case Oculus Quest 2) and click Build and Run.
- Observe ~1sec block
recordStart on record start.
Can you also please tell me what version of FMOD you are using?
1 Like
Both of the people who have reported it to me are running entirely on Windows PC, using a Quest headset as a tethered headset rather than a standalone device. Sorry I think I wasn’t very clear about that!
Here’s what I believe should reproduce it:
- Don’t change any Windows input or output settings
- In Unity start recording the mic, choosing the “Oculus Virtual Audio Device”
- If you’re using Dissonance set
MicrophoneName = "Oculus Virtual Audio Device". Docs.
- If you’re using just Unity call
Microphone.Start("Oculus Virtual Audio Device", etc.... Docs.
- Run the application, either in editor or in build. Observe 1 second startup time.
As for FMOD version I asked the person who has reported this to me and so far they’ve seen it in:
- Unity (no idea what version of FMOD that is),
- version
1.10.12 (this is the version their game is using)
- “The latest version on the asset store” as of just a few days ago, which they tested while debugging this issue. Presumably
2.02.15.
Thank you for the additional information- I am finding I can reproduce this issue inconsistently. Usually it’s taking ~300ms, which is about the same as other devices, but a few times I have found it can take >1sec.
I can’t seem to influence the result with any settings, so I’m unsure of what to suggest in terms of workarounds unfortunately. In any case, I have passed this onto the Dev team to look into- thank you for bringing this to our attention.
1 Like
Do you know if there has been any progress on this issue? A few more peope have contacted me reporting that this is causing a problem for them with Dissonance+Quest, but I don’t have any workaround to give them at the moment.
We have reproduced this issue outside of Unity, and have determined the slowest point is a >500ms blocking call into IAudioClient::Initialize, which we call into for the Winsonic and WASAPI output types.
As part of the Windows Audio API, I would expect Unity to be making the same calls as us- and I would expect any audio client on Windows to be doing the same thing for that matter.
I can see a few reports online about IAudioClient::Initialize blocking for a long time with some devices on Windows, but there’s not much in the way of answers. We are initializing in shared mode, which is known to incur higher latency than exclusive mode, so perhaps this is related.
As with any slow and unavoidable process, I think the best a workaround would be to start the slow process ahead of time. This may not be feasible for all users, but if you/they move the call to System.recordStart into a loading scene or during some idle time, you can then call System.playSound when the user needs it and begin playback instantly.
In the “record_enumeration” Core API example we show how you can separate your calls to System.recordStart and System.playSound, giving the impression of instant record/playback.
I have suggested to the Dev team that we move the input client’s IAudioClient::Initialize call ahead of time to account for this potentially slow process. Otherwise the only other option is to open a ticket with Meta to see if they have an explanation for their slow initialization time. Please let me know if you have any other questions.
Thanks for the very detailed update!
As with any slow and unavoidable process, I think the best a workaround would be to start the slow process ahead of time.
I don’t think this is feasible for the Unity Microphone API, but we do have another package that uses the FMOD mic system with Dissonance directly so I might be able to rearrange the work there. It’s tricky, because Dissonance doesn’t even exist in the scene until it’s already too late, but I can probably add in some kind of “long lived” behaviour that can optionally be dropped into an early loading screen to begin the mic.
Otherwise the only other option is to open a ticket with Meta to see if they have an explanation for their slow initialization time.
I’ll keep escalating up the chain 
