Severe latency issues with Ableton Live 10 and Axe-Fx 3

Glassjaw0

New Member
Hey All,
So as the title suggests, I'm trying to record bass and guitar through the axe FX into Ableton 10 using a mac pro 2.4 GHZ quad core intel i5 w/ 5gb 2133Mhz ram.
Im also using the Axefx as my interface and recording via USB.

When I direct monitor everything was peachy, I wrote some riffs to the drums I programmed and hit record. The playback was behind and it was unbearable.
Naturally I went to the preferences and played around with the latency settings. The DAW reports 3.9ms input latency, 4 ms of output latency and 0.27 ms overall latency due to driver error compensation. Tried recording again, still gross. On the axe-fx I went to setup -> IO-> audio -> played with usb buffer size. Tried again and its still gross.

When Im recording and tracking the overall CPU usage on the daw and macOS utility report ~ 25% CPU usage. The plugins for the programmed drums report 1.8ms / 84 samples of latency.

The part that really boggles me is the other day I recorded a bass riff, with programmed drums then switched and was direct monitoring guitar over the two and the drums were not delayed after recording. I'm not certain what button the monkeyman pushed but I'm going to take the blame for probably changing something I shouldn't have. :weary:

Any suggestions much appreciated. I know ableton probably deeper then I know the axe fx so Im coming here first.

Appreciate it.
 
I haven’t used Ableton in a bit since I switched to Logic, but is there a latency compensation option? Typically you will want to turn that off. From my understanding that will dynamically change how it compensates the latency making it hard to predict. Also are you running any plugins, like I know in Logic if I run iZotpe Ozone it introduces latency, so I wait to put that on any tracks until after I’m done tracking.
 
Can you explain what the problem is? If you’re monitoring direct while recording guitar, any latency won’t matter, so I don’t understand what would be unbearable.

Or are you saying the recorded guitar track is out of sync with the drum track? If so, you may need to adjust your driver error compensation preference.
 
Last edited:
Latency shouldn't be an issue with "Monitor" turned off on your tracks in Ableton. I use the Axe 3 with the default settings without issue. You don't have to mess with the buffer size or latency compensation or anything like that. In fact I even use Ozone while playing because it doesn't add latency to the Axe, so you might try that Werpinater because it is possible. I couldn't do that when I used to use amp sim plugins because of the massive amount of latency it added, but you don't have to listen to your guitar signal processed through your DAW when using the Axe so the added latency doesn't matter.
 
remove anything from your master bus and add it back after you record. A lot of DAW's predict for latency even if it's disabled. I was recording vocal stems into a template in Logic that I had setup and it had stuff on the master bus that was causing latency, even when disabled. annoying but was an easy fix. Just saved that channel strip setting and loaded when I was ready to mix and bounce.
 
remove anything from your master bus and add it back after you record. A lot of DAW's predict for latency even if it's disabled. I was recording vocal stems into a template in Logic that I had setup and it had stuff on the master bus that was causing latency, even when disabled. annoying but was an easy fix. Just saved that channel strip setting and loaded when I was ready to mix and bounce.

The OP is monitoring direct, so plugin latency is irrelevant. In your case, it sounds like you are monitoring through your daw? If so, and if the plugin latency is causing problems, leave the plugins alone and turn on low latency mode while recording. That will remove any plugins with significant latency from the signal chain.
 
Latency shouldn't be an issue with "Monitor" turned off on your tracks in Ableton. I use the Axe 3 with the default settings without issue. You don't have to mess with the buffer size or latency compensation or anything like that. In fact I even use Ozone while playing because it doesn't add latency to the Axe, so you might try that Werpinater because it is possible. I couldn't do that when I used to use amp sim plugins because of the massive amount of latency it added, but you don't have to listen to your guitar signal processed through your DAW when using the Axe so the added latency doesn't matter.
remove anything from your master bus and add it back after you record. A lot of DAW's predict for latency even if it's disabled. I was recording vocal stems into a template in Logic that I had setup and it had stuff on the master bus that was causing latency, even when disabled. annoying but was an easy fix. Just saved that channel strip setting and loaded when I was ready to mix and bounce.
Typically I direct monitor my Axe, unless I’m playing through a specific plugin to match other tracks. I run into latency that sucks specifically when using my electric drums to track MIDI and the same for vocals or mic’d acoustic, when running plugins on my master bus.

It sound like the OP might be referring to the tracks being out of sync on playback, that the direct monitoring puts it in place, but playback shifts it to compensate. So OP try checking your DAW’s input buffer size. Sometimes when I track long performances like band or choir concerts I jack the buffer all the way up on my fairly old MacBook Air to make sure I don’t get any write errors, and that has brought me latency of near 2-10 seconds before. So that could be leading to a time alignment issue if that buffer is too high.
 
It sound like the OP might be referring to the tracks being out of sync on playback, that the direct monitoring puts it in place, but playback shifts it to compensate. So OP try checking your DAW’s input buffer size.

DAW's will compensate for the buffer size, so, no, there's no point to changing the buffer size. But, due to driver errors, sometimes that compensation is incorrect, regardless of the buffer size. That's why Live has a preference for correcting that compensation. So, leave the buffer size alone, but adjust the driver error compensation.
 
DAW's will compensate for the buffer size, so, no, there's no point to changing the buffer size. But, due to driver errors, sometimes that compensation is incorrect, regardless of the buffer size. That's why Live has a preference for correcting that compensation. So, leave the buffer size alone, but adjust the driver error compensation.
I have experienced changes in latency with buffer size before, but it does depend on the setup. I have run low buffer sizes with low latencies before, but had write error and crashes, so I went to a large buffer with massive latency, but it didn’t matter for the project because it was one continuous live performance for editing after the event.
 
Sure, various factors will affect what is the best buffer size for anyone to use in their particular situation. And, latency of course changes with buffer size. But, the issue here isn't latency. There will always be latency. The issue is the compensation for that inevitable latency.
 
The OP is monitoring direct, so plugin latency is irrelevant. In your case, it sounds like you are monitoring through your daw? If so, and if the plugin latency is causing problems, leave the plugins alone and turn on low latency mode while recording. That will remove any plugins with significant latency from the signal chain.
he said it was fine when monitoring direct but had latency when recorded, I'm referring to recording.
 
I have been using Ableton Live 10 and initially struggled with the same issue. The key was indeed turning the Monitor to Off rather than In or Auto. The problem was instantly resolved after a month or so of frustration!

I have Axe FX III direct to a Scarlett 18i8 (3rd generation) via XLR cables, that is connected to computer is an iMac w/Big Sur via USB C.

Cheers
Image 1-8-21 at 10.39 AM.jpeg
 
Hey All,
I apologize for my non-response, was a busy week.

I was hearing out of sync playback after I recorded however.....

I was just playing around with ableton and your suggestions and everybody solved small parts of it.
  • The largest improvement was changing monitoring to off.
  • After that I changed my buffer size back to what I originally had it set at. (512 samples)
  • used driver error compensation which turned out to be -27ms and said resulted in 0.02ms delay

Now everything seems to jive much better. Im still going to play with it and see if I can dial it in tighter.
but for now at least I can listen to the playback.

Appreciate everyones time!
 
The Axe-Fx III does not advertise its own latency in its USB descriptors; even if it did, it's unclear if the OSX USB 2 Audio class drivers even would make use of those fields (see https://forum.fractalaudio.com/threads/logic-pro-recording-delay-setting.157412/#post-1877210).

The latency of the Axe-Fx III itself will vary depending on the value set for "USB Buffer size". I've mentioned this in the past, so I'll just link to it:

https://forum.fractalaudio.com/thre...-latency-issues-with-usb.137958/#post-1636630
https://forum.fractalaudio.com/thre...-latency-issues-with-usb.137958/#post-1637251
https://forum.fractalaudio.com/thre...cy-troubleshooting.139828/page-3#post-1658325
 
Have you ever heard of another class compliant audio device with this problem?
Not often, but sometimes pops up in gearslutz, for example: https://www.gearslutz.com/board/new...mpensation-correctly-when-keeps-changing.html

And see the help for Ableton live:
https://help.ableton.com/hc/en-us/articles/115000234830-Driver-Error-Compensation-FAQ

Which audio interfaces require a DEC adjustment?


A class-compliant device (also known as plug-and-play) is one that doesn't require extra drivers to connect to your computer. Usually DEC should be used for devices running in class-compliant mode.


On the other hand, interfaces which require their own native drivers report accurate latency values, meaning that there should be no need to adjust DEC for devices running in native mode.

So definitely not an Axe-Fx only thing; For example the USB descriptors for an RME babyface pro in class compliant mode also don't advertise TE_LATENCY_CONTROL. However, RME does provide proprietary drivers even for OSX and the babyFace can switch between class-compliant and the proprietary mode. I suspect that when operating in proprietary mode, the driver then advertises the correct latency numbers.

Also I figure it mostly goes unnoticed until someone starts tracking double/triple/etc guitars with really tight timings.
At the default of 256 in the Axe-Fx III we are talking about an additional round-trip latency of 256x4 (at least) or around 21ms, which is definitely noticeable.

I personally just set the Axe-Fx III USB Buffer size to 32, then measure the additional loopback latency and put in in reaper as on compensation offset of the ASIO reported latency. It's not something you have to change often.
 
For the OP (@Glassjaw0), you can use the RTL utility to measure the overall roundtrip latency (https://oblique-audio.com/rtl-utility.php)

You can easily do this with the Axe-Fx III by connecting a cable from say output 3 L to input 2 L and create a preset that routes IN USB->OUT 3 Block. Make sure to increase the OUT 3 knob in the front.
In RTL, set the output to OUT 7 (In U Block L) and the input to IN 7 [In 2 L] and measure.

If you don't care about the ADC/DAC latency, then you don't need any cable, just create a patch with In USB->OUT 2 and in RTL, set the output to OUT 7 (In U Block L) and the input to IN 3 [OUT 2 Block L] and measure.

Take the measurement, substract the DAW reported latency in samples (both input and ouput) then divide by 2 - that should go into your DEC value.
After this adjustment, when you record, the original source you tracked against should be pretty much in sync with what you recorded.
 
So definitely not an Axe-Fx only thing; For example the USB descriptors for an RME babyface pro in class compliant mode also don't advertise TE_LATENCY_CONTROL. However, RME does provide proprietary drivers even for OSX and the babyFace can switch between class-compliant and the proprietary mode. I suspect that when operating in proprietary mode, the driver then advertises the correct latency numbers.

Correct me if I’m wrong, but your research doesn’t quite answer your original question: if the AxeFX supplied TE_LATENCY_CONTROL, would that fix the problem?
 
Back
Top Bottom