FM3 Internal/Passthrough Latency Measurements - Surprising Results?

F

Finger_My_Chord

New Member
I recently took some thorough measurements of the FM3's internal latency (analog inputs to analog outputs). Turns out there's a typical RTL of around 5ms with a simple amp/cab setup, with potential to increase to 8+ ms when an effects loop (Input2/Output2), drive blocks, and other misc. effects are added. Definitely a surprising find, however it confirms my own suspicions. I'm decently sensitive to latency once it crosses the 5ms threshold, and switching to the FM3 this year had me questioning if something was wrong with my monitoring setup.

The full test results are below. This was measured using both the Oblique RTL Tool as well as manual measurements within my DAW to confirm. A baseline was taken with my audio interface (RME Babyface Pro, +3.8ms latency) and subtracted from each measurement in order to give a compensated result of the FM3's latency. Multiple measurements were taken across multiple sample rates/buffer sizes on my interface - all compensated FM3 measurements were consistent.

Compensated RTL (ms)vs. Baseline (ms)
FM3 (Blank patch, In 1 to Out 1, analog out)2.6BASELINE
FM3 (Blank patch, In 1 to Out 1, SPDIF out)2.3-0.3
Normal patch +fx loop8+5.4
Normal patch +no loop5.5+2.9
FX Loop only (In 1 -> Out 2 -> In 2 -> Out 1)5.2+2.6
Amp only3.9+1.3
Amp+cab4+1.4
Drive Only3.3+0.7
Drive (Mix = 0% )3.3+0.7
Amp + cab + drive4.7+2.1
Amp + cab + drive + verb4.7+2.1
Notes:
Time-based effects (modulation, reverb, delay, etc) do not have an affect on RTL
A bypassed block is treated as if it's removed from the chain
Latency increases even with the Drive Block mix at 0%
Measurements were retaken with another audio interface (Presonus Quantum 2), with identical results

"Normal Patch" used:
FM3 normal patch.png


Now, some of you are probably saying what's the big deal, 8ms is hardly noticeable to most players. However, this results in a few problems:
  1. Adding effects with inherently higher latencies now becomes compounded and more extreme. For example, my DigiTech Drop has a typical latency of around 15ms on its lower settings, which was workable with tracking in its own isolated environment. However, with the FM3's own latency added into the mix, it becomes much more intrusive and the "feel" suffers significantly.
  2. Parallel signal chains experience phasing issues when they are asymmetric. For example, I like to use patches with an amp/cab path in parallel with a DI fuzz path. However, due to the extra +1.4ms that the Amp/Cab blocks create vs the +0.7ms that the Drive Block creates, the signals are audibly out of phase. A workaround would be to manually add a 100% wet delay block to the fuzz path, set to 0.7ms to realign the signals (currently not possible).
  3. Tracking with multiple outputs at different nodes in the signal chain has the same phasing issues. My original plan was to route my guitar's DI signal through the FM3's SPDIF Out so that I could 1) reamp and 2) more easily align phase+transients when editing in my DAW. However, the DI track will always be offset with the FM3's main output. Since the FM3's latency can vary depending on which effects are enabled, setting a manual offset within my DAW wouldn't be a catch-all solution.
____
My question is: Is this the expected behavior from the FM3? I've searched and read previous claims that the Axe FX III has a total RTL of around 1-2ms, which is for sure different than what I'm seeing with the FM3. I've also read that the SHARC+ processors used in the FM3 have a much longer pipeline than the AXEIII's Keystone processors. Is this the result of that, or is the signal processing additionally being slowed down to compensate for the lesser processing power?

What's most surprising to me are the I/O latencies from just running In1>Out1 (2.6ms) and an effects loop made from Out2>In2 (+2.6ms). I would have assumed these would be an order of magnitude lower here, since these are ultimately what's contributing to the bulk of the FM3's latency.


I hope this post doesn't come off as accusatory, as I'm genuinely curious about the inner workings of the FM3. I would love some insight on what I'm seeing here and if there are any suggestions to the problems that I'm trying to work around!
 
Last edited:
Some additional measurements for fun. The pitch block was more inconsistent with measurements due to its nature. I could only take measurements down to -2 semitones before the RTL Utility stopped recognizing the signal. I was also surprised to find out that the Digitech Freqout has a +6.4ms latency when set to Momentary Mode (Dry = On).

vs. Baseline (ms)
Pitch Block measurements:
Virtual Capo (no shift, tracking =5)+23.4
Virtual Capo (-2 semitones, tracking =5)+28.9
Virtual Capo (-2 semitones, tracking =10)+37.8
Whammy (no shift)+30.0
Digitech Freqout (Momentary Mode, Dry On, disengaged)+6.4
Digitech Freqout (Latching Mode, bypassed)+0.0
Digitech Drop (1-2 semitones)+15.0
 
Last edited:
You don't say what buffer size you're using, but those numbers look pretty darn good to me.
 
I see. You mentioned RTL, which doesn't make sense for what you're measuring, so that confused me.

Anyway, for a digital processor, those numbers still look pretty good to me, so my answer to your question remains the same.
 
GlennO said:
I see. You mentioned RTL, which doesn't make sense for what you're measuring, so that confused me.

Anyway, for a digital processor, those numbers still look pretty good to me, so my answer to your question remains the same.
Click to expand...
Ah, I suppose I should've used the term "passthrough" instead of RTL. Sorry for the confusion.

The numbers are fine, but the biggest problem comes from the phasing issues with parallel chains, since right I'm not aware of any way to properly align them.
 
Finger_My_Chord said:
Ah, I suppose I should've used the term "passthrough" instead of RTL. Sorry for the confusion.

The numbers are fine, but the biggest problem comes from the phasing issues with parallel chains, since right I'm not aware of any way to properly align them.
Click to expand...

Yeah, that's always a challenge. But, that's a binary artifact. In other words, it either exists or it doesn't. Altering the processing latency will change the comb filtering, but not eliminate it.
 
Finger_My_Chord said:
What's most surprising to me are the I/O latencies from just running In1>Out1 (2.6ms) and an effects loop made from Out2>In2 (+2.6ms). I would have assumed these would be an order of magnitude lower here, since these are ultimately what's contributing to the bulk of the FM3's latency.
Click to expand...

From that it would appear to me that the bottleneck is the input A/D converter. Losing 0.3ms going between the analog out and SPDIF makes sense as you're removing that D/A step, but yes it seems the A/D takes a disproportionate amount of time.
 
Finger_My_Chord said:
Thanks for the quick response, I appreciate the team taking a look!
Click to expand...
So we've discovered there is an excess 32 samples of latency on each I/O pair. I can't guarantee this will be fixed for the upcoming 1.06 firmware but, if not, it will be fixed for the firmware after that. This will reduce the In -> Out latency to around 1.7 ms. This will reduce your "FX Only" patch to around 3.4 ms.
 
vetteboy79 said:
From that it would appear to me that the bottleneck is the input A/D converter. Losing 0.3ms going between the analog out and SPDIF makes sense as you're removing that D/A step, but yes it seems the A/D takes a disproportionate amount of time.
Click to expand...
0.3 ms is hardly "disproportionate". The converters used in the FM3 have 12 samples of latency which is 0.25 ms at 48 kHz. This is quite typical.
 
FractalAudio said:
So we've discovered there is an excess 32 samples of latency on each I/O pair. I can't guarantee this will be fixed for the upcoming 1.06 firmware but, if not, it will be fixed for the firmware after that. This will reduce the In -> Out latency to around 1.7 ms. This will reduce your "FX Only" patch to around 3.4 ms.
Click to expand...

I've just received my FM3, as my very first Fractal unit, and now I don't know if I'm more amazed by it or by how quick the issues are collected and analyzed... :oops:
 
Last edited:
FractalAudio said:
So we've discovered there is an excess 32 samples of latency on each I/O pair. I can't guarantee this will be fixed for the upcoming 1.06 firmware but, if not, it will be fixed for the firmware after that. This will reduce the In -> Out latency to around 1.7 ms. This will reduce your "FX Only" patch to around 3.4 ms.
Click to expand...

Wow, I was not expecting such a fast investigation and turnaround. I appreciate this tons, thanks so much!
 
I love the community support that this company has. A few years back I was using a certain 13-pin guitar synthesizer unit from a certain company and the V-Guitar forum collected a list of bugs in the device and we waited... and waited... and finally after about two years a v1.5 firmware came out that fixed... absolutely none of our discovered bugs. v1.5 is still the one and only firmware update the unit ever got. But they did throw in a bunch of new factory presets, so, yay?
 
Finger_My_Chord said:
I recently took some thorough measurements of the FM3's internal latency (analog inputs to analog outputs). Turns out there's a typical RTL of around 5ms with a simple amp/cab setup, with potential to increase to 8+ ms when an effects loop (Input2/Output2), drive blocks, and other misc. effects are added. Definitely a surprising find, however it confirms my own suspicions. I'm decently sensitive to latency once it crosses the 5ms threshold, and switching to the FM3 this year had me questioning if something was wrong with my monitoring setup.

The full test results are below. This was measured using both the Oblique RTL Tool as well as manual measurements within my DAW to confirm. A baseline was taken with my audio interface (RME Babyface Pro, +3.8ms latency) and subtracted from each measurement in order to give a compensated result of the FM3's latency. Multiple measurements were taken across multiple sample rates/buffer sizes on my interface - all compensated FM3 measurements were consistent.

Compensated RTL (ms)vs. Baseline (ms)
FM3 (Blank patch, In 1 to Out 1, analog out)2.6BASELINE
FM3 (Blank patch, In 1 to Out 1, SPDIF out)2.3-0.3
Normal patch +fx loop8+5.4
Normal patch +no loop5.5+2.9
FX Loop only (In 1 -> Out 2 -> In 2 -> Out 1)5.2+2.6
Amp only3.9+1.3
Amp+cab4+1.4
Drive Only3.3+0.7
Drive (Mix = 0% )3.3+0.7
Amp + cab + drive4.7+2.1
Amp + cab + drive + verb4.7+2.1
Notes:
Time-based effects (modulation, reverb, delay, etc) do not have an affect on RTL
A bypassed block is treated as if it's removed from the chain
Latency increases even with the Drive Block mix at 0%
Measurements were retaken with another audio interface (Presonus Quantum 2), with identical results

"Normal Patch" used:
View attachment 72063


Now, some of you are probably saying what's the big deal, 8ms is hardly noticeable to most players. However, this results in a few problems:
  1. Adding effects with inherently higher latencies now becomes compounded and more extreme. For example, my DigiTech Drop has a typical latency of around 15ms on its lower settings, which was workable with tracking in its own isolated environment. However, with the FM3's own latency added into the mix, it becomes much more intrusive and the "feel" suffers significantly.
  2. Parallel signal chains experience phasing issues when they are asymmetric. For example, I like to use patches with an amp/cab path in parallel with a DI fuzz path. However, due to the extra +1.4ms that the Amp/Cab blocks create vs the +0.7ms that the Drive Block creates, the signals are audibly out of phase. A workaround would be to manually add a 100% wet delay block to the fuzz path, set to 0.7ms to realign the signals (currently not possible).
  3. Tracking with multiple outputs at different nodes in the signal chain has the same phasing issues. My original plan was to route my guitar's DI signal through the FM3's SPDIF Out so that I could 1) reamp and 2) more easily align phase+transients when editing in my DAW. However, the DI track will always be offset with the FM3's main output. Since the FM3's latency can vary depending on which effects are enabled, setting a manual offset within my DAW wouldn't be a catch-all solution.
____
My question is: Is this the expected behavior from the FM3? I've searched and read previous claims that the Axe FX III has a total RTL of around 1-2ms, which is for sure different than what I'm seeing with the FM3. I've also read that the SHARC+ processors used in the FM3 have a much longer pipeline than the AXEIII's Keystone processors. Is this the result of that, or is the signal processing additionally being slowed down to compensate for the lesser processing power?

What's most surprising to me are the I/O latencies from just running In1>Out1 (2.6ms) and an effects loop made from Out2>In2 (+2.6ms). I would have assumed these would be an order of magnitude lower here, since these are ultimately what's contributing to the bulk of the FM3's latency.


I hope this post doesn't come off as accusatory, as I'm genuinely curious about the inner workings of the FM3. I would love some insight on what I'm seeing here and if there are any suggestions to the problems that I'm trying to work around!
Click to expand...

Is it possible make this with new fw 2.00?
I know its lot of work but if they wrote that they make some changes in i/o circuit.
Thanks
 
You must log in or register to reply here.
Back
Top Bottom