FM3 Internal/Passthrough Latency Measurements - Surprising Results?

H9 has analog bypass, not analog dry through. The wet/dry mix of its effects is done digitally.

It does have a kill dry option through so you can run an analog dry path externally if desired.
 
Last edited:
I thought I’d mention that I resolved my latency issue. Turns out that in Reaper 5.x there’s a prescribed procedure on how to resolve the issue. Now that I’ve performed it I have zero latency issues. Look for the Reaper video laying out the “Loopback Test” procedure. I imagine there’s a similar procedure with other DAW’s. I don’t think there’s a way to do it in GarageBand yet fairly confident the more sophisticated DAW packages provide a way to compensate for latency. Just to note Fractal posted an article addressing the issue. Good luck. Fred
 
...such as the H9 :)
Some digital pedals also have an analog dry signal path so there effectively no latency on that portion of the signal. Depends on the pedal in question.

depending on the effect (ie a 100 wet effect with 0 dry) and on how one wants to use the pedal - some prefer dry thru off on a digital pedal in which case the full adda latency would apply (ie I guess some may want dry thru off if the pedal effect had some converted dry mixed in to avoid possible noise caused by the difference in timing of the converted dry pedal signal component compared to dry thru)
 
Yeah perception is a weird thing sometimes.

Always liked this one:

"In one recent test, psychologists asked 32 volunteers to sample strawberry yogurt. To make sure the testers made their judgments purely on the basis of taste, the researchers said, they needed to turn out the lights. Then they gave their subjects chocolate yogurt. Nineteen of the 32 praised the strawberry flavor. One said that strawberry was her favorite flavor and she planned to switch to this new brand."

On more than one occasion I've sat here subtly tweaking an EQ or Compressor plugin in a DAW track only to later realize I accidentally had the plugin bypassed the whole time. When the difference is subtle our brains can play some weird tricks on us.

I'm a self-acknowledged beer snob.

One time at the bar my buddy blindfolded me and put 8 random beers from the tap in front of me, including some of my favorites and some I didn't like.

I didn't guess a damn one correctly, even to the point of being completely wrong about what style or type.

That said, I still order the good stuff 🍻
 
...such as the H9 :)
was just checking my H9 which I use infrequently, and it actually (to my surprise though I always used 100% digital) does not have analogue dry thru - it does have a kill dry which kills the digital dry to make the digital fx 100% wet (assumes the user is routing analogue dry around the H9 in parallel).
 
Last edited:
I'd wager that in a blind test, most players would be hard pressed to recognize any single digit latency difference.
if the sound coming through the speakers is not too loud, and you can hear the unamplified/acoustic sound of strings...it’s a different story.
 
Bump. Any difference now with 5.0.2? I just did a somewhat crude measurement with a y cord out of my guitar one side directly into daw, the other guitar->fm3 in1->fm3 out1->daw. Comparing the start peak of the waveforms from the two daw inputs in logic I'm getting about 3ms with just an INPUT1->OUTPUT1 patch on my FM3 and and about 7ms with my main patch with amp/cab/reverb.

-Aaron
 
It was improved after reporting it through tech support, roughly by 0.65 ms. My new results on 5.0.2:
in->out: 2 ms (down from 2.65)
in->amp+cab->out: ~3.35ms (down from 4 ms)
in->drive->amp->cab->out: ~4.07ms (down from 4.7ms)
 
It was improved after reporting it through tech support, roughly by 0.65 ms. My new results on 5.0.2:
in->out: 2 ms (down from 2.65)
in->amp+cab->out: ~3.35ms (down from 4 ms)
in->drive->amp->cab->out: ~4.07ms (down from 4.7ms)

Does latency increase with additional blocks (phaser, reverb, delay, PEQ, etc.) .... maybe even reaching a breaking point for some?

I swear I can hear/feel a difference running 2 individual FM3s in parallel. One is setup as a bare bones dry rig, and the other as a
loaded wet rig. I thought I was nuts at first, but now I can't not notice the difference. That wet FM3 lags behind the dry FM3.
 
Aside from a couple of obvious exceptions (look ahead compressor, drive, amp), no, adding blocks doesn't increase latency.
I think you are incorrect and the FM3 dynamically allocates processing power and latency is increased with added blocks. Obviously some will add significantly more than others.
 
I think it's important to read this exchange:

I'll take a shot at this with some wild speculation...

I suspect that in order to minimise switching time and [many] other overheads... it isn't a case of 'oh, this newly selected preset uses a flanger, I'll create an instance of a flanger object' but rather that he instantiates all of the allowed instances of all the allowed block types in memory at power on and simply* switches the internal virtual wiring per preset. IOW, volatile memory constraints.

Well, that's my guess anyway.

[*] relatively simple... no dynamic destruction/creation of blocks required or memory management on a change of preset

And @FractalAudio's response.

I'm with @GlennO on this.

The easiest way to create a stable and consistent system where we, as programmers, know how to fit within the constraints of the CPU and memory, is to load everything at once, then work within that. At that point it wouldn't matter what preset was loaded or how much memory or CPU it needed, every block would be available and accounted for. If some weren't used? Well, so what?

The opposite scenario, where blocks were loaded on demand, and switched out when they're not needed, would only cause inconsistent latency and switching times. People would never stand for that.

In a general computing system we wouldn't do that because the user can be allowed to wait as things are loaded and unloaded, but that's not what the modelers are. They have tight requirements for switching and latency MUST be within specified bounds so waiting around isn't an option.

I just finished a spreadsheet comparing CPU usage of each block in each of the modelers, for my own curiosity. What was interesting is the consistency of the results for each block in each modeler. Sure, the FM3 blocks take more CPU than the FM9 which takes longer than the FX3… usually, but what stuck out was how, knowing those times makes it easy to figure out how much time it'd take to process in a worst case preset scenario. Loading blocks in on demand could result in wildly varying times in response, whereas, if they're always available it's very static and stable.
 
Last edited:
I think you are incorrect and the FM3 dynamically allocates processing power and latency is increased with added blocks. Obviously some will add significantly more than others.

I am only asking because when I run dual FM3s in parallel one surely seems to be lagging. I found this
thread where someone measured the latency of the FM3 relative to demands, and my reading of it was
that latency does increase relative to the demands of a particular preset.
 
I am only asking because when I run dual FM3s in parallel one surely seems to be lagging. I found this
thread where someone measured the latency of the FM3 relative to demands, and my reading of it was
that latency does increase relative to the demands of a particular preset.
The only time I can see that latency would increase is if a preset is already pushing the CPU past 80%, to the point it's struggling to process its sub-processes. Processing the sound is the #1 priority, and the system WILL sacrifice other sub-processes ability to complete in order to keep the sound quality. That means updating the front panel and responding to knobs, and USB/MIDI and their talking to the editor will take a hit. Eventually, if the load is bad enough, the modeler begins disabling the blocks with the heaviest demands, again, to keep the sound flowing. If it's too bad, it will disable the sound so it can respond to the front-panel controls and the USB -> Editor connection in hopes that the user will pay attention to the flashing warning.

If they're truly parallel, and one isn't triggering the other, then test this by running the same preset on both FM3, sending a pulse into them both while recording their output in a DAW, then measuring their response times.
 
I think you are incorrect and the FM3 dynamically allocates processing power and latency is increased with added blocks. Obviously some will add significantly more than others.
No, adding blocks doesn't add latency (with a few exceptions I mentioned above). That's not how digital signal processing works. That's the very reason there is a cpu limit.
 
No, adding blocks doesn't add latency (with a few exceptions I mentioned above). That's not how digital signal processing works. That's the very reason there is a cpu limit.
I mean...we have measured proof amp and cab blocks add latency, we all know pitch blocks will. I guess you are basing this off modulation/delay/reverb working by creating a secondary signal mixed into the primary dry signal? Yea...presumably that wouldn't add latency, but I believe any effect which is 100% wet would add some degree of latency.
 
I mean...we have measured proof amp and cab blocks add latency, we all know pitch blocks will. I guess you are basing this off modulation/delay/reverb working by creating a secondary signal mixed into the primary dry signal? Yea...presumably that wouldn't add latency, but I believe any effect which is 100% wet would add some degree of latency.
ie: modulation fx have delays built in, so, @100% wet they will introduce latency due to the definition of the effect. Turn the delay parms down to minimum in a 100% wet mod block (ie "Min Delay" in Flanger, "Delay Time" in Chorus...) and latency will fall to almost the same as with the block off (those delays don't go all the way down to 0 so some small latency will always remain for these at 100% wet). At the same time, CPU will remain consistant with these blocks on or off since, as noted above, all blocks' CPU resource needs are allocated regardless of on/off.

Edit: this is why I remain somewhat confused about some of the latency reporting topic conversation, since, in the case where someone is turning 100% wet modulations on or off during recording (or pitch on/off or comp with look ahead on/off ...), those changes will introduce latency fluctuations whose values depend on the settings in blocks going on/off (ie mod delay values, comp look ahead value ...), or via modifiers attached to those settings where possible - so in those cases, no constant latency compensation value will work with that sort of change happening within the recording performance - I don't see how a static "latency report" to DAW for a given preset/session in this dynamic recording performance scenario is possible.
 
Last edited:
Back
Top Bottom