FM9 Latency - Around 5ms?

I used RTL Utility to fire some pings through my FM9, Kemper and QC this evening out of curiosity.

On the FM9;
With an input, amp, cab and output blocks, I'm getting 221 samples / 4.6ms.
When I add in a Drive block I get 257 samples / 5.35ms.
My main lead sound in my main patch which is a drive, amp, cab, delay, reverb and filter is at 296 samples which is 6.16ms.
Delays and reverbs don't seem to do anything to the latency though I’m not sure why my lead scene has more latency.

Kemper seems to hover around 3.3-3.5ms unless you enable "Constant Latency" whereby it then hovers around 4.9ms.

Quad Cortex totally depends on how many Captures/amps you have in a preset.
If I go in, amp, IR, out, I get 106 samples / 2.20ms.
Replacing the amp with a capture, I get 121 samples / 2.52ms.
In a loaded example, using two rows and having 6 captures in the preset but only using one at a time with an IR, it's between 279 and 281 samples, so lets say 280 which is 5.8ms.
If I stack two captures at once (say a TS9 and an amp) it’s 315 / 6.56ms.
If I replace the OD capture with the OG OD block with a TS9 and stack it into an amp, I get 300 / 6.25ms.
The first patch you see on QC, Brit 2203, comes in at 213 / 4.43ms, roughly identical to the FM9's baseline.

What does all this mean? I presume I'm not measuring it as accurately as it should be as Cliff has stated it's 3.3ms with an amp and a cab, but that said, if I take 1.3ms off of all of the above, that makes the Kemper unrealistically fast at 2ms, so I can't imagine they're that far out? Either way, weirdly enough, despite being the fastest, the Kemper seems to feel the most disconnected in a weird way so I'm not sure what all of this means ultimately..!
 
Last edited:
I used RTL Utility to fire some pings through my FM9, Kemper and QC this evening out of curiosity.
I presume I'm not measuring it as accurately as it should be as Cliff has stated it's 3.3ms with an amp and a cab,

You're measuring a different kind of latency...usb i/o latency. That latency is relevant for recording. This thread is about analog i/o latency, which is the latency you hear when you're playing the FM9 and monitoring at the analog output. (Or at least that's what Cliff is referring to. I don't know what Keybi is measuring since he didn't provde any details.)
 
You're measuring a different kind of latency...usb i/o latency. That latency is relevant for recording. This thread is about analog i/o latency, which is the latency you hear when you're playing the FM9 and monitoring at the analog output. (Or at least that's what Cliff is referring to. I don't know what Keybi is measuring since he didn't provde any details.)
I didn't use USB.

I went analog I/O using an Apollo Twin X Quad, subtracting the 179 samples that the interface needs to do its thing. I tested that first, then took that away from the readings of each unit. If I use the I/O plugin in Logic, which discounts any latency of the interface, I get very similar results.
 
The theoretical latency of the FM3/9 is:
In -> Out - 96 samples = 2ms
In -> Amp -> Out -160 samples = 3.33ms
In -> Amp -> Cab -> Out - 160 samples = 3.33ms (Cab block doesn't add any latency unless IR has leading silence)
in -> Drive -> Amp -> Cab -> Out - 192 samples = 4ms
None of the other blocks add latency.

It appears that perhaps there's a bug in the FM9 and it's adding an extra 64 samples of latency. I will discuss this with the head engineer on that project tomorrow.
 
I didn't use USB.

I went analog I/O using an Apollo Twin X Quad, subtracting the 179 samples that the interface needs to do its thing. I tested that first, then took that away from the readings of each unit. If I use the I/O plugin in Logic, which discounts any latency of the interface, I get very similar results.
That all sounds right. How did you measure “do it’s thing”? (A more common way to measure the latency is by using a pair of parallel signal paths)
 
Output to input.
In that case I think your question about whether you’re doing it right can be answered with “yes”. Just be careful you don’t use the digital loopback routing in your interface since that would overestimate the latency :).
 
In that case I think your question about whether you’re doing it right can be answered with “yes”. Just be careful you don’t use the digital loopback routing in your interface since that would overestimate the latency :).
Related question for you if you don't mind - a while ago there was discussion related to interfaces that have analogue monitoring vs those that have digital monitoring and therefore add latency to monitoring even when trs/xlr in/out cabling is used. I was trying to figure out which mine is (Roland Octa) - it's not written anywhere so to test I connected a cable from one of my interface's outputs to one of it's inputs, and then from my DAW (Logic) I used the IO Utility to send a ping to the interface output I'd cabled out of. The round trip of the ping to detection at the input I'd cabled to, showed as -1 samples which is 0 latency (I think). Do you think that proves my interface has all analogue monitoring? I was not sure why it read -1 and not 0, so to confirm I was hooked up right for loopback, I put Axfx3 in that loopback (InterfaceOut > AxIn1, AxOut1 > InterfaceIn with just Input1/Output1 blocks in the grid). Repeating the ping test, I got 69 samples which seems correct to latency numbers I'd seen here for Axefx (about 1.5ms in and out combined).
 
As is so often the case with these kinds of things, there are multiple ways to go about it, but I would say what you measured is the difference between the reported and actual loopback latency, but yes, that might serve as proof.

IMHO a more direct way to answer your question would be to take a test signal and split it into two. Send one to the interface input and monitor that to an analog output. Take that monitor output and the other half of the test signal and send those into a stereo input of an interface (one to the left and the other to the right).

If your monitor path is analog, the left and right signals will match perfectly. If the monitor path is digital, one will lag behind the other.

Note that this technique can also be used to measure the latency of an amp modeler and has some advantages over the technique that involves measuring a loopback.
 
The theoretical latency of the FM3/9 is:
In -> Out - 96 samples = 2ms
In -> Amp -> Out -160 samples = 3.33ms
In -> Amp -> Cab -> Out - 160 samples = 3.33ms (Cab block doesn't add any latency unless IR has leading silence)
in -> Drive -> Amp -> Cab -> Out - 192 samples = 4ms
None of the other blocks add latency.

It appears that perhaps there's a bug in the FM9 and it's adding an extra 64 samples of latency. I will discuss this with the head engineer on that project tomorrow.
Is 4ms basically the worst case scenario in FM3/9 (not considering eg pitch effects)? I'm wondering whether adding another drive block will add another 0,67ms or if running two amps on the FM9 will add more latency? I would assume two drives in series would add more latency.
 
Wasn't there a test where someone measured the latency added by each type of block? I can't seem to find it now.
 
As is so often the case with these kinds of things, there are multiple ways to go about it, but I would say what you measured is the difference between the reported and actual loopback latency, but yes, that might serve as proof.

IMHO a more direct way to answer your question would be to take a test signal and split it into two. Send one to the interface input and monitor that to an analog output. Take that monitor output and the other half of the test signal and send those into a stereo input of an interface (one to the left and the other to the right).

If your monitor path is analog, the left and right signals will match perfectly. If the monitor path is digital, one will lag behind the other.

Note that this technique can also be used to measure the latency of an amp modeler and has some advantages over the technique that involves measuring a loopback.
Whilst I do agree with you, the reported Kemper latency vs the result I got aren’t a million miles away so it makes me think that whilst it’s probably not a 1:1 accuracy re the samples it’s not wildly incorrect. MORE THAN HAPPY to be wrong however!

Edit: Also, I watched Leo Gibson’s videos on modeler latency and some of the QC results I got are actually quicker than he stated in his most recent QC investigation. Not by much - like 0.2ms - but enough to note. That said, probably not enough to be concerned about either way.
 
Back
Top Bottom