Magnet Region is slow to trigger

Hi! Recently I swapped to using a single timeline and magnet regions to swap between ambiences and songs in our game. I’m using several magnet regions, some of which are quantized, and some of which aren’t, for things I want to snap to instantly. The region conditions are using a single “User: Labeled” parameter.

It works, but instead of being instant, the non-quantized transitions still take a long time to trigger, maybe something like 250-500ms if I had to guess. Is this just a limitation of magnet regions or is there anything we can do to make it react faster?

Our previous solution, starting and stopping events ourselves, was instant, so I don’t believe it has anything to do with buffer size.

I’m afraid we’ll need more information to diagnose this issue. Does the issue occur only in-game, or can it be reproduced in FMOD Studio? Are you able to take a video of a session in which this occurs?

I should mention that ~20 ms of latency is expected when using transition markers or magnet regions with parameter trigger conditions, due to the unavoidable limitations of scheduling sample data playback.

ok here’s a video, you can see the delay from clicking the scene to the audio changing

(make sure volume is on)

it’s the same ingame and in studio, and definitely much longer than 20ms. playing events is a LOT lower latency than switching between magnet regions.

1 Like


also, this is the magnet region for “silence” which has no transition timelines or quantization or anything

also: this is FMOD studio 2.01.11, windows 10

Probably one of 2 reasons: either you have a seek speed set on your Scene parameter, or the assets in that event are set to “Stream” which will always introduce latency as it loads/unloads.

Checking both those things, it looks to me like it’s Instant, and none of the assets are streaming


Is the following sufficient to explain the latency you’re seeing?

The latency demoed in the video i posted seems a lot higher than 40ms, right? I can’t bring it into a video editor at the moment to get a precise number but its almost a whole quarter note at 138bpm, which would be in the ballpark of ~500ms. And the magnet region for “Silence,” which I’m switching to, has no quantization.

Are you able to send us a copy of a project containing an event that exhibits the behavior, so that we can investigate the cause? You can upload packaged projects in the uploads tab of your profile page, provided you’ve registered a game project you’re working on with us.

how do i register a game?

You can register a game by going to and clicking the “Register new project” button. Registering is free, but gives us a better idea of what kinds of games people are making with FMOD.

ok, that’s pending approval now

okay, this is uploaded to my profile now

Just pinging this thread to make sure there aren’t any more steps I need to take

Having investigated the project you uploaded, it looks like the latency you describe is happening when you switch from playing sound to playing silence.

The latency of the transition itself is only affected by the ~40 ms delay that I mentioned earlier - but there’s ~400 ms fadeout being applied to the instrument that’s stopping, meaning that it remains audible for a few moments after the transition is complete. This fadeout exists to prevent the instrument from stopping playback too abruptly, which would likely result in an audible and undesireable pop, as there’s no way to guarantee the transition will occur on a zero crossing.

I recorded this clip by holding headphones up to the microphone. The click you hear is the mouse up event as i change the value of “Scene” from Epoch to Silence, and it’s takes a full ~550ms for the audio to stop. Also as you can see from the waveform, that time is definitely not spent on any kind of fade out.

Also, 400ms would be a REALLY long time for a stopped event to fade out over, are you sure that’s right? It’s definitely not happening in this clip, to be sure.


(also, after posting i realized the selection i made to hilight the time between mouse up event and sound stopping might be obscuring the “click”, so here’s that waveform without the selection on it in ableton.)

Oh, and here’s the audio itself.

Upon further examination of your project, we’ve discovered that some of its assets actually are set to stream. You can find a list of all streaming assets in your project by typing “#streaming” into the assets browser search bar, or by clicking the assets browser search bar’s magnifying glass icon and selecting “Filter by Streaming Assets” from the menu.

This is relevant because having any streaming assets in an event increases whole event’s schedule delay so as to allow streams sufficient time to buffer when a parameter value is changed. One of your project’s streaming assets, “god.wav,” is present in the event used in your video; if you set this asset to not stream, you should see a reduction in latency.

Ah, interesting. I thought I had removed all the streaming assets because none showed the blue “stream” tag in the browser, but i guess those were just being covered up by other tags like “#modifed”. Seems like multiple of these should be able to render at once, yeah?

After making it so no assets anywhere in the project were streaming, for good measure, it seems like the latency from mouse click to transition is ~315 ms in the editor, and ~200 ms in the game.

This is a good improvement, but 200ms still seems like a long round trip from player input to sound, no? While I was testing the game was running at 144fps, and sending the signal to change the song on the same frame as the mouse input (i verified). So that couldn’t contribute more than 7ms to the timing.

This is the code I’m initializing FMOD with, if it matters

These docs say that the default is 1024x4 ~= 80ms latency. So the track switching is still another 120ms behind where it could be, right?

Also, is there any guidance on what buffer size+count settings are appropriate for what platforms?

To echo what Joseph has said, I have had projects where an instrument fade or an AHDSR caused transition latency like you’re experiencing. Sometimes I just couldn’t figure it out and just recreated the event from scratch so that I could catch exactly where I went wrong.

1 Like