Hi, I’m using FMOD and I’m experimenting a big latency when playing sounds. I think the latency is about 140ms.
I’m on Windows 10 64 bits, high end CPU, using FMOD C# bindings supplied by FMOD and mostly using raw C# (not unity)
My init is
result=lowLevelSystem.setSoftwareFormat (0,SPEAKERMODE.DEFAULT,0); // so that can get same frequency as output and avoid some extra latency
result=system.initialize (256,
FMOD.Studio.INITFLAGS.NORMAL,
FMOD.INITFLAGS.NORMAL | FMOD.INITFLAGS._3D_RIGHTHANDED,
IntPtr.Zero);
I’m playing the particular sound through FMOD Studio events.
I use system.getEvent at the start of the game, then each time I want to play the sound, I call the event’s createInstance, and finally effectInstance.start to play the sound.
I’ve been searching the forum and used lowLevelSystem.setDSPBufferSize (512,4); to reduce latency a bit (maybe from ~140 to ~100)
but that is still too big for my project, and I don’t feel like further reducing the DSP buffer size. (256 reduces it to ~80)
All sounds are added into FMOD Studio as wav, although I don’t know is FMS changes the format. The sound is “correctly trimmed” (no extra silence before the sample)
Could you please suggest any more actions to further reduce the latency? It seems like there are 60ms extra latency somewhere not caused by the DSP buffer.
KakCat, this is what I did to get my latency down to about 20ms:
Firstly, any audio asset that should have low-latency playback must NOT be marked as streaming in FMOD Studio. Compression doesn’t seem to impact latency, but streaming certainly does.
Secondly, an FMOD event needs to first be “buffered” by playing it, then immediately pausing it. Then, when it comes time to play the event, just set pause to false (rather than calling the play method).
These two things was all I needed. I reverted my DSP buffer settings back to default after making these changes and that latency was still super low.
I’ve tried the pause method with my version and seemed not to change anything. Then I decided to move to FMOD 2 64bits (long overdue). After changing some code to adhere to the new API your trick seemed to reduce latency a bit, but unfortunately not as much as you could. Increasing the DSP buffer still increases the latency though.
Although the latency now is more bearable than before (50-70 ms) with 512, I’m wonder what I’m doing wrong
I’ll try going with the pause trick for the moment, but I’ll have to really think how to structure the code so that it’s not a mess to just play a sound.
As mentioned previously, the way to reduce latency with FMOD is to use the Core level System::setDSPBufferSize. The documentation contains certain caveats you need to be mindful of.
How do you measure that latency in the first place?
Is there a way you can determine what is going out the speaker jack, so you don’t need a physical setup (speakers/microphone, input app) to determine latency?
It depends on what exactly you’re trying to measure.
If you want to measure the overall latency between an input and it effect, then recording your own input and the result audio output is usually the best way to do it.
If you want to measure latency that is specifically a result of FMOD, then recording a profiler session via live update, observing when a specific API command is processed in the API calls view, and comparing it to when the audible effect of that command occurs is a better option.
Again, it depends on what exactly you need:
A recorded profiler session saves the captured output of the FMOD system
Many audio drivers have a loopback mode or something similar, which will loop back output as an input
Screen and audio recording programs or functions can record audio output, and can also be helpful in determining how the output syncs with video
Is there an equivalent for this in the FMOD Studio API specifically? I’m making a rhythm game and would love to lower latency but I’m pretty sure setting DSP buffer sizes is exclusive to the FMOD Core API
The Studio API is built on top of the Core API, so it is entirely possible. To do so, after creating your Studio system, but before initializing it, use Studio::System::getCoreSystem to get the underlying Core system, and then use System::setDSPBufferSize on the retrieved Core system to set the DSP buffer size.
