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.
