FM3 Internal/Passthrough Latency Measurements - Surprising Results?

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.

And yet it somehow has worked with every device I've owned until the FM3.
 
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.

It's important for the Axe-FX to report the latency correctly because:

1) Almost all block types introduce no latency at all. That includes cab blocks. While some IRs have leading dead space, the cab block itself has no latency.
2) It's extremely rare to use a delay effect at 100% wet. It's almost always mixed with some dry, either by using it in parallel to a dry path or by turning the mix control down to less than 100%. Anybody who does use it at 100% mix obviously doesn't care about latency anyway :).
3) The few blocks that do introduce latency add an amount of latency that is very small compared to the amount of the error in the latency reporting. A drive block and an amp block add roughly a millisecond of latency, which is imperceptible. The amount of error caused by the latency reporting bug is usually around 12 milliseconds, which is very perceptible.
 
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.

Isn't that what the OP of this thread did and measured?
 
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.

This is meshing with my experience more than whatever technical speak that goes over my head is. :)

I am not dismissing people's superior knowledge, and I have a lot to learn. That being said, I also
know what I am hearing/feeling---and that is why I am asking. I can't replace people's knowledge
with my experience that one FM3 is lagging behind the other when I am running one of them with
more blocks than the other.

Also, I can eliminate both FM3s and run an all analog signal path and not have any issues. Still entirely
possible I am doing something wrong, though.
 
So on other devices you can set up a 100% wet delay of X ms, and turn it on mid recording performance and the DAW will align correctly?

There are 2 different issues at play.

1. End to end internal latency greater than it should have been, which has been corrected.

2. Reported USB latency, which is wonky. Take an HX Stomp and use it as a sound card. When you play back the recorded track the parts sound aligned. This isn't the case with the FM3 which will not sound in time with backing tracks without adjusting guitar track either manually or setting up an offset in the DAW. So for example, I set up a 100ms 100% wet delay in an HX stomp and record it the play back would be something like 102 ms behind the beat, just like it sounded when recorded. But the FM3 would be like 114-116 ms behind the beat, not aligned as it was when tracking and expressing a greater latency than the end to end internal latency of the device.

I gave up trying to set up offsets within reaper and have reverted back to using a sound card.
 
There are 2 different issues at play.

1. End to end internal latency greater than it should have been, which has been corrected.

2. Reported USB latency, which is wonky. Take an HX Stomp and use it as a sound card. When you play back the recorded track the parts sound aligned. This isn't the case with the FM3 which will not sound in time with backing tracks without adjusting guitar track either manually or setting up an offset in the DAW. So for example, I set up a 100ms 100% wet delay in an HX stomp and record it the play back would be something like 102 ms behind the beat, just like it sounded when recorded. But the FM3 would be like 114-116 ms behind the beat, not aligned as it was when tracking and expressing a greater latency than the end to end internal latency of the device.

I gave up trying to set up offsets within reaper and have reverted back to using a sound card.
I get that the latency reporting in a static situation is apparently incorrect in Axfx and is the bug that's been reported - but, your response above to the example I gave (blocks adding latency turning on and off during recording performance) suggested other devices would report correctly in the dynamic on/off scenario, which I'd be surprised were the case given the on/off aspect - for a static non changing preset, then no, I'm not surprised other devices do it correctly.

Sorry to be painfully precise, but the latency discussion needs a lot of precision given the various nuances, all of which are interesting aspects to discuss - difficult though when several converge lol!:
  • cpu usage tracking vs:
  • latency tracking on a preset that is changing mid performance (ie your 100ms 100% wet delay turns on mid performance, (or, a more common example: pitch is turned on)) vs:
  • latency tracking on a preset that stays static vs:
  • the amount of latency associated to variously config'd drives / cabs / amps / fx @ 100% wet vs:
  • amount of added latency (none I expect) associated to presets containing fx @ < 100% wet vs:
  • amount of latency to DAW vs:
  • accuracy of latency reported to DAW vs ...
The last being the only one of these that is def confirmed at issue in Axfx afaik, but the discussion can often wind around all of the above o_O
 
Last edited:
I get that the latency reporting in a static situation is apparently incorrect in Axfx and is the bug that's been reported - but, your response above to the example I gave (blocks adding latency turning on and off during recording performance) suggested other devices would report correctly in the dynamic on/off scenario, which I'd be surprised were the case given the on/off aspect - for a static non changing preset, then no, I'm not surprised other devices do it correctly.

Sorry to be painfully precise, but the latency discussion needs a lot of precision given the various nuances, all of which are interesting aspects to discuss - difficult though when several converge lol!:
  • cpu usage tracking vs:
  • latency tracking on a preset that is changing mid performance (ie your 100ms 100% wet delay turns on mid performance, (or, a more common example: pitch is turned on)) vs:
  • latency tracking on a preset that stays static vs:
  • the amount of latency associated to variously config'd drives / cabs / amps / fx @ 100% wet vs:
  • amount of added latency (none I expect) associated to presets containing fx @ < 100% wet vs:
  • amount of latency to DAW vs:
  • accuracy of latency reported to DAW vs ...
The last being the only one of these that is at issue in Axfx afaik, but the discussion can often wind around all of the above o_O

Sorry...miscommunication. If the block is preset regardless of state it should likely impact the patch latency. All I'm getting at is ADDING blocks can and will impact latency. Based on post 1 we can see adding a drive block adds latency. I suspect this is the case with all effects, however the way modulation and time based effects are typically used (in box either with mix control or parallel path 100% wet) and how CPU efficient they are would be negligible outside the weird wet/dry parallel use case in which even a very small amount of latency could result in some phase cancellation if any dry signal exists in the wet path.
 
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.
Most blocks do not add latency. The only blocks that add latency are Drive and Amp. The reason being that they oversample and oversampling adds latency.
 
Back
Top Bottom