Event playback latency


I’ve been dealing with some event playback latency with FMOD 2.01.11 and FMOD 2.02.03 in a particular event.
I have a complex damage event that is called together with an attack event, and it’s built with many referenced events inside Parameter Sheets:

Inside each one, I have more referenced events, that has other referenced events, etc:

When I play the game in Unity Editor, I can clearly hear a latency between the attack and the damage event. I tried to check if enabling the preload of the sample data in the FMOD configuration plugin would work but the result is the same.
I’m also trying to test them in the Sandbox, and it’s the same playback issue.

What I’m missing here? Is this a bug or should I configure the damage event in a different way?


It’s not clear from your screenshot which of those event instruments represent “the attack” and “the damage event.”

If it’s the “~impact” and “~gore” instruments, then latency is expected behavior, as they start at different positions on the timeline.

If it’s the “damage source” and “elemental hit” instruments, then we’ll need more information to determine the cause of this issue. What are the contents of those event instruments?

Given that the latency occurs when you audition the events in FMOD Studio, it’s likely that this issue is unrelated to loading modes, and that there’s some feature of the instrument content that is causing the latency.You seem to be using multiply-nested events. Try auditioning at each level of nesting depth in the event editor window to try and isolate which level the latency is introduced at.

Hey! Sorry about being unspecific.
I found the problem. One sound file inside a multi-instrument was set as STREAM, making all other sounds wait to be played.
One thing that isn’t clear to me is that why didn’t this single sound would be delayed while others would play in time. I mean, there was a probability to play the streamed sound because of the multi-instrument and even if it wasn’t playing, the delay was still happening.

Streaming assets are loaded in an unusual fashion that differs from that of other assets: They are loaded piecemeal in real time, such that only the part of the asset that’s currently playing or just about to play is loaded into memory at any given time. This reduces the amount of memory required to load the asset, but also makes it impossible to pre-load streaming assets or schedule them to play with sample-accurate timing. I suspect this was the cause of the delay you observed - but without seeing the event, we can’t say for sure.

In any case, I’m glad to hear you were able to resolve the issue.

Thanks for the explanation, @joseph!
Here’s the event isolated: link
When I started to prepare the project to send to you, the issue returned to this new project. So let’s investigate!

The only asset that is being streamed is ELEMENTAL_Fire_Critical_Impact_01 while the rest are not. I’ve created a Sandbox scene (Playback Issue) with three events:

  • A simple sound that I’m using to check the playback sync (T)
    *The actual sound that is being delayed (hit taken) and it’s also playing the same sound T.wav
    *A duplicated event of hit taken but without the referenced events (hit taken duplicated T)

If you play T and hit taken, you will hear a delay every time, even if the streamed asset wasn’t picked by the multi-instrument. However, if you set ELEMENTAL_FIRE_etc as “not stream” you’re still gonna hear a delay between the T and the T.wav in the hit taken event.
If you test playing T and hit taken duplicated T, you won’t hear any delay between the events.

There’s also a bug with Sandbox that you’ll need to close the window every time you make a change on the loading mode of a sound to actually hear the change. I don’t know if you are aware of that!

Am I missing something? Please let me know.

I hope that helps!

Thanks for giving us access to your project. The delay you’ve observed is, as I suspected, caused by the known and expected differences in how events containing streaming assets are scheduled.

I’ve added this issue to our bug tracker.