(Sylvain) #1


Since I started to use Fmod with UE4 (one year), I’m experiencing a latency problem and now I couldn’t continue my project without solving it

The UE4 audio system have no audible latency but when I use Fmod there is one

I took my portable audio recorder to see how long is the latency between the moment of the mouse click and the moment the sound is heard
I got 156ms

My system setup:

  • PC Desktop Core i5
  • Audio Windows: 16/44100
  • Waveforms samples: 16/44100
  • Fmod Master Bank: PCM/44.1
  • DSP Buffer: 512
  • Buffer count: 4
  • All Banks: Loaded
  • All Sample Data: Loaded
  • Studio Update Period 10

I tried to play with all these settings plus this one “studio.window.browserCurrent().automatableProperties.noLookahead = true”

But now I wonder if it could have a link with the blueprint speed while using the Mouse click node ?
Here is the blueprint used:

I repeat there is no audible latency while using Blueprint with UE4 built-in Audio system

Can someone have the same issue ?
Can you have some tips and tricks ?

(Geoff Carlton) #2

I’ll look into this and get back to you.

(Geoff Carlton) #3

Those are the best initialization settings to use. The good news is that we have a large improvement in latency coming in 1.08, which will be released in the next 4 weeks or so. That should shave off close to 50ms of latency in the underlying wasapi output mode, with no changes required at your end.

I notice you’ve set up the format to 44100 which matches most windows installations. That’s good, since it avoids a resampler. I’m going to add a UE4 setting to the integration (which will default enabled), which will match the output mode to the system where possible.

I’ve investigated latency using our soon to be released 1.08 branch to see what sort of numbers we’ve got and how close we are to optimal.

Lets look at the minimum latency we expect with wasapi shared mode. I can take either the FMOD code, or else the sample code microsoft ships with, and cut the ring buffer size down to the bare minimum, ignore any software mixing, and just force signal into the wasapi buffer as soon as possible. On my machine, which is similar to the one you have posted, I get ~65ms round trip latency.

If I take that same core wasapi code, and set it up to use 512x4 buffering, we get ~95ms round trip latency. That is just copying in raw data into the wasapi callback as soon as possible. So that is the lowest we’d expect while having a reasonable amount of buffering to make sure we are safe from audio hiccups or dropouts.

When playing a simple event with a single sound on the timeline in UE4 with our FMOD pre-release 1.08, I can see the next mix after the blueprint click is about 90-100ms, and sound comes through one mix +11ms after that. That is because we schedule events to occur in parallel while we are doing the software mix. That is going to be as close to optimal as we can get it, since we’ve created the instance, put it into the software mixer and then got signal mixing through within one mix block.

I said simple event above because Studio adds one more mix of latency for complex events to make sure all tracks and sounds are in exact sample-accurate synchronization with each other. When playing an event with more than one sound, the scheduling adds one more mix of latency, so another +11ms. This is a very conservative measure, and the one thing that we have some wiggle room on. That additional delay can be tweaked FMOD_STUDIO_EVENT_PROPERTY_SCHEDULE_DELAY if it is critical that sounds avoid that additional delay, but that is a setting only exposed via programming, not the FMOD Studio at this stage.

(Sylvain) #4

Hello Geoff

Thanks for taking the time to reply I will wait the 1.08 build to see if it’s acceptable.

I’m not an expert with coding but from what I understand I should expect something around 117 ms. I found these numbers are quite high…

Wasapi = 65ms
Buffer = 30ms
Studio mix = 22ms (complex events)