Latency reporting to DAW

FYI, this audio misalignment problem has nothing to do with re-amping. It's a recording problem. If you do any recording using your Axe-FX as your audio device, you'll run into this audio misalignment, regardless of whether you do re-amping or not.

As for how many people notice the problem, I suspect a lot of people notice something is wrong when they record their Axe-FX, but instead of pursuing a solution, they simply give up trying to record it :).
I haven't really noticed the problem quite as overtly during my initial "scratch tone" recording.

I'm assuming that this I because DAWs can set to autocompensate for this (at least to an extent)? Whereas with reamping there are more variables at play which exacerbates the issue?

I use it to reamp but use it via spdif and another interface. I’m not seeing any of this behavior. I’m of the belief use you gear to do one thing it does well. Deviate from that at your peril.
thanks for the reminder on this workaround, i'm adding it to my summary of issues post
 
I haven't really noticed the problem quite as overtly during my initial "scratch tone" recording.

I'm assuming that this I because DAWs can set to autocompensate for this (at least to an extent)? Whereas with reamping there are more variables at play which exacerbates the issue?
The problem is just as severe when recording, even a slight amount more than when re-amping. You’ll find details here:

https://forum.fractalaudio.com/threads/latency-compensation-measurement.177851/
 
I have updated my post to remove the inaccuracies and add more info about the 128 Buffer Reset.

To be fair, I should mention that not too far back @Admin M@ and @amandio both communicated and worked with me trying to isolate the unstable/jittery offset thing, so I definitely don't think these things are being ignored.

For better or worse, I've been doing my best not to let threads die...but often times it does seem like only a handful of people use this thing to reamp...which seems crazy hahahah

I use mine for reamping almost every day. Luckily with mine the offset seems to be constant/stable. So the amount of latency doesn't seem to change.
 
I have a few questions about this issue. If you send a signal to the fractal thru your reamping chain (with every block off but IN/OUT) then back to the DAW, you can observe the total latency by aligning the 2 signals and measuring in either samples or ms. Is the latency the same whether or not the blocks are active?
If using spdif, I believe there will still be nominal offset due to both host computer and the fractals processing. I’m not sure how/why this would increase using the fractal as the interface and reamping via USB. They’re both digital mediums and I don’t think one will process the signal any faster than the other.
I’d really love to see an offline render for reamping. I think it would cure a lot of this. The fractal can ping the chain all the way to the DAW and back, render the files and give you the latency number to either manually nudge or set the track to nudge (studio one). Doing things in real time, stuff changes. I don’t know how much the host CPU has to do with latency numbers but it has an OS to run and constant tasks to perform other than audio tasks making an exact science in this issue nearly impossible.
 
AXE FX III has separate firmware for the USB stuff. Upgrade process is the same, though. You can use Fractal Bot to update it.
What exactly is the reason for having that as a separate download? It's 83KB. That's a "K", so it's much too small to worry about long downloads. Why not include it in the dsp firmware .syx? The only result of making it a separate download that I can see is that it causes confusion :).
 
I have a few questions about this issue. If you send a signal to the fractal thru your reamping chain (with every block off but IN/OUT) then back to the DAW, you can observe the total latency by aligning the 2 signals and measuring in either samples or ms. Is the latency the same whether or not the blocks are active?
If using spdif, I believe there will still be nominal offset due to both host computer and the fractals processing. I’m not sure how/why this would increase using the fractal as the interface and reamping via USB. They’re both digital mediums and I don’t think one will process the signal any faster than the other.
I’d really love to see an offline render for reamping. I think it would cure a lot of this. The fractal can ping the chain all the way to the DAW and back, render the files and give you the latency number to either manually nudge or set the track to nudge (studio one). Doing things in real time, stuff changes. I don’t know how much the host CPU has to do with latency numbers but it has an OS to run and constant tasks to perform other than audio tasks making an exact science in this issue nearly impossible.
Offline is not a good solution. Especially if you need to reamp with a wah or change effects etc.
 
Offline is not a good solution. Especially if you need to reamp with a wah or change effects etc.
I see your point, but with an average of 10 tracks to reamp, Id much prefer to offline render 9 of them and work the wah on the 10th in real time. Or simply use a plugin wah and automate it.
 
I posted my experience in this thread, I was experiencing a huge lag both recording and reamping. The latency compensation I had to manually adjust in my Daw in order to align a click track with itself when recording a loopback was huge (over 1000).

I updated the USB firmware as @amandio suggested (thank you, I never noticed that firmware existed) and my particular case (Macbook 13" 2015, Big Sur 11.2.3, Logic 10.5.1) is apparently solved. I am surprised, since apparently that alone is not supposed to solve the problem?

It is too soon to tell, since I really want to double check this is stable, but my latency compensation in my DAW is now zero (!) and I don't feel there is a significant delay in my recordings, nor when I reamp. I recognise my tempo and my playing in my recordings. And before that, there was so much phasing in my reamps that were unusable (unless aligning by hand of course).
 
Last edited:
FYI, this audio misalignment problem has nothing to do with re-amping. It's a recording problem. If you do any recording using your Axe-FX as your audio device, you'll run into this audio misalignment, regardless of whether you do re-amping or not.

As for how many people notice the problem, I suspect a lot of people notice something is wrong when they record their Axe-FX, but instead of pursuing a solution, they simply give up trying to record it :).
Yes, it's a big problem and always has been. I've just learned to manually adjust my DI's, and then measure my reamps with a click track as those latency times vary depending on the preset and how much processing is being done. It's a hassle, but the Axe is 2nd to none with tones, so it is what it is I suppose. Hoping this can be resolved at some point as it is IMO the biggest issue with the Axe.
 
I’m not going to pretend to know, but I do imagine reamping would be faster (less latency) than live performance even. The daw needs to shoot a digital audio track to the fractal, get processed, then shoot it back to the DAW, all staying digital. Your live performance needs to hit Fractals converters first, then go thru the same chain of events. So, if your live performance drops in your recordings in a place where it sounds and feels like where it belongs, what changes when reamping? A few samples off is really splitting hairs that cant be heard or felt on a single direct signal where phase alignment isn’t a possibility. If I understand the issue right, you’d have to be about 44 samples late to move the track a single millisecond behind the intended spot. I’m not sure what kind of latency numbers the rest of you are seeing, but if its more than a ms or 2, something’s wrong. How low can the Fractals buffer go and what do the RTL numbers in your DAWs look like? I can get my RTL around 4ms with my Apollo at a 32 sample buffer. I’m pretty happy with that. I do not feel any latency at that number. I never felt like I had to nudge around any reamped tracks, either but I’m always at 32 samples with an external interface, not the fractal as an interface.
 
I’m not going to pretend to know, but I do imagine reamping would be faster (less latency) than live performance even. The daw needs to shoot a digital audio track to the fractal, get processed, then shoot it back to the DAW, all staying digital. Your live performance needs to hit Fractals converters first, then go thru the same chain of events. So, if your live performance drops in your recordings in a place where it sounds and feels like where it belongs, what changes when reamping? A few samples off is really splitting hairs that cant be heard or felt on a single direct signal where phase alignment isn’t a possibility. If I understand the issue right, you’d have to be about 44 samples late to move the track a single millisecond behind the intended spot. I’m not sure what kind of latency numbers the rest of you are seeing, but if its more than a ms or 2, something’s wrong. How low can the Fractals buffer go and what do the RTL numbers in your DAWs look like? I can get my RTL around 4ms with my Apollo at a 32 sample buffer. I’m pretty happy with that. I do not feel any latency at that number. I never felt like I had to nudge around any reamped tracks, either but I’m always at 32 samples with an external interface, not the fractal as an interface.
You can see details on the difference re-amping makes to the latency in the latency compensation instructions thread, but the amount of the latency is a bit off the point of this thread. The point here is the Axe-FX is not correctly compensating for the latency, regardless of what it is, low or high. In your case, you're turning down your audio buffer size to force the latency to be low, but that's unnecessary in a correctly functioning system: When monitoring direct, the RTL is irrelevant when recording an Axe-FX....it's only the compensation that matters.
 
You can see details on the difference re-amping makes to the latency in the latency compensation instructions thread, but the amount of the latency is a bit off the point of this thread. The point here is the Axe-FX is not correctly compensating for the latency, regardless of what it is, low or high. In your case, you're turning down your audio buffer size to force the latency to be low, but that's unnecessary in a correctly functioning system: When monitoring direct, the RTL is irrelevant when recording an Axe-FX....it's only the compensation that matters.
I think (again, maybe I’m wrong) this is one of the issues we can run into when using a device for multiple purposes at once regardless of how its marketed. All my ADC comes from the DAW, in my case Studio One. I use an Apollo and plenty of plugins which all report latency to the DAW, everything lines up perfectly. for any and all external gear, I use pipeline which is a plugin routing interface specifically to use external hardware. Pipeline pings, gets a latency number back, adjusts by number of samples and it all just works. I’ve never felt the need to ping the fractal to adjust a reamped track, but maybe now I will. And yes if I chose to monitor direct, the buffer size wouldn’t matter and in theory my tracks should all just line up. I’ve never tried, my computer is beefy enough to DAW monitor at 32 samples buffer regardless of what’s going on. I rarely see CPU spikes, even during mixdown and forget its on 32 samples half the time.
So I imagine if the DAW never knows what the latency number is, it cant possibly adjust the track. ADC is probably about 15 years old by now. I remember for a while working in Protools and this had to be done manually, anyway. ADC wasnt yet available!
 
I think (again, maybe I’m wrong) this is one of the issues we can run into when using a device for multiple purposes at once regardless of how its marketed.
As for whether it's reasonable to expect this feature to work properly on an audio interface built into an outboard processor, IMHO the answer is "yes". Your Apollo is basically the same as an Axe-FX: primarily a dsp co-processor but with the secondary additional feature of a built-in audio interface, yet it has no trouble with usb i/o.
 
As for whether it's reasonable to expect this feature to work properly on an audio interface built into an outboard processor, IMHO the answer is "yes". Your Apollo is basically the same as an Axe-FX: primarily a dsp co-processor but with the secondary additional feature of a built-in audio interface, yet it has no trouble with usb i/o.
I can appreciate your point, but a quick look at the UA forum will show you the scores of tortured souls who cant get a 3000 dollar interface to play back iTunes or YouTube in windows without clicks and pops. Me being one of them. I’ll say this; at least Fractal gives a shit and seems to be committed to gathering the data needed to fix this latency issue. UA really couldn’t care less. No interface is perfect. I’m behind the company thats committed to the service after the sale. The USB end of UA I’m unfamiliar with. The TB interfaces honestly shouldn’t even be marketed as windows compatible until they commit to making them work.
 
Thank you Amandio. Your efforts are appreciated. Just to confirm my earlier results though, I'm not seeing any difference in latency amount, latency stability, or latency reporting with this update. I've been looking at both versions pretty carefully the past few days and I'm not seeing any change. (MacOS 11.6.4, AxeFX III Firmware 19.01).
 
Thank you Amandio. Your efforts are appreciated. Just to confirm my earlier results though, I'm not seeing any difference in latency amount, latency stability, or latency reporting with this update. I've been looking at both versions pretty carefully the past few days and I'm not seeing any change. (MacOS 11.6.4, AxeFX III Firmware 19.01).
same here at least as far as latency measurement is concerned - went from 1.08 to 1.11 this morning with reboot + measurement before / after - no change. Also noticed, I still have to reset buffer on each reboot so it is set correctly and matches the visual control.
 
After some more testing tonight, I am pretty convinced that the "reset to 128" bug is what causes the unstable/jittery reamps.

If that is the case, setting your USB Buffer to 128 and then adjusting your DAWs offset should be a stable workaround. (Of course even with this there can still be some slight variance of a few milliseconds at times.)

Someone else should probably corroborate this though.
 
Even if you are going through a mixer or other gear wouldn’t you still have that latency as it needs to be hooked up to your machine? Or does it come down to USB vs Thunderbolt vs other connectivity standards? I’m really showing my ignorance here, and I’m a computer guy 🙄 just not necessarily a recording gear guy. And I will buy additional gear to eliminate this problem too. We all know how frustrating it is
It's real simple. You have to look at the physical analog signal being able to operate within an optimal frequency for signal detection temporal advancement. All you need to do is temporarily shift the signal into a frequency which will advance detection of the analog signal and offset or eliminate signal transmissions and processing delays.
 
Last edited:
Back
Top Bottom