Latency reporting to DAW

Watt McCo said:
Right. It seems folks are wanting a solution that gives a reamp track that aligns, to the sample, exactly with the original, and I'm just trying to imagine a scenario where that happens without some user-effort. Not certain you would get that result even if the III/3 were accurately reporting latency to the DAW?
Click to expand...
Not everyone has the same experience where it is always less than 1ms off. Sample perfect 100% aligned reamps are the "most optimal" scenario, but that doesn't mean a "pretty damn good" scenario is unacceptable. A lot of people get the "pretty damn good" scenario, which is great, but I would like to get to the bottom of why its not like that across the board.

VSTs amp sims already hit that "most optimal" scenario where changes are instantly in place. So we know that IS a possibility because both Brand L and Brand N provide that solution one way or another. I get that there are limitations and potential IP threat problems with VST, but it's still a hurdle in the Fractal ecosystem for some people.

Another issue is that all of the information about all the different USB settings in the manuals/wiki is pretty vague. This makes it hard to know what an optimal setting for your system is and whether that's part of the problem. And while you can sort of infer what all those options mean or do--some of these issues make it hard to know whether your assumptions/settings are correct. Correct me if I'm wrong, but I don't think I've seen a bugfix for the USB buffer resetting after reboot, and I know that I still experience the unstable offset. Identifying whether its a hardware, driver, setting, or whatever kind of issue is difficult because it isn't apparent what all of the settings actually do -- or if they work correctly to begin with.

All of this is why I try engaging with the forums and with support: so that we can identify these problems and perhaps collectively come up with solutions.
 
Last edited:
sixtystring said:
You're still assuming everyone has the same experience as you where it is always less than 1ms off. Sample perfect 100% aligned reamps are the "most optimal" scenario, but that doesn't mean a "pretty damn good" scenario is unacceptable. You get the "pretty damn good" scenario, which is great, but a handful of people have chimed in and said they don't get that.

VSTs amp sims already hit that "most optimal" scenario where changes are instantly in place. So we know that IS a possibility becasue both Brand L and Brand N provide that solution one way or another. I get that there are limitations and potential IP threat problems with VST, but it's still a hurdle in the Fractal ecosystem for some people.

Another issue is that all of the information about all the different USB settings in the manuals/wiki is pretty vague. This makes it hard to know what an optimal setting for your system is and whether that's part of the problem. And while you can sort of infer what all those options mean or do--some of these issues make it hard to know whether your assumptions/settings are correct. Correct me if I'm wrong, but I don't think I saw a bugfix for the USB buffer resetting after reboot, and I know that I still experience the unstable offset. Identifying whether its a harware, driver, setting, or whatever kind of issue is difficult because it isn't apparently what all of the settings actually do -- or if they work correctly to begin with.

All of this is why I try engaging with the forums and with support: so that we can identify these problems and perhaps collectively come up with solutions other than "well it works good enough for me so I don't get why people care"
Click to expand...
Just to clarify, as I tried to do in my original post, I'm not saying anyone should just suck it up or deal with it because I'm getting results that work fine for my uses just be setting a single offset and walking away. It's a $2k+ device that is advertised as having a world-class audio interface; of course properly reporting latency is part of a world class audio interface and of course we should expect the Fractal stuff to be able to do that, especially several years after release. Even though my fix is fairly simple compared to yours, I'm still pretty annoyed about it. Nothing in any of my posts was meant to discourage anyone from engaging with the forum, or with support, or meant to discourage Fractal from considering this a top-priority problem that needs to be addressed.

My post about whether one would get sample perfect alignment with reamping via SPDIF and/or whether sample perfect reamping alignment is a reasonable expectation with hardware were simply to explore what reasonable expectations of a properly functioning modeler-with-integrated-USB-audio-interface should be. Again, that's not meant to tell you to stop engaging with the forums or support on getting a fix for the problem that does exist, its merely meant to make sure there is a reasonable expectation of what even the most perfect fix possible might be capable of achieving.
 
sixtystring said:
Correct me if I'm wrong, but I don't think I saw a bugfix for the USB buffer resetting after reboot, and I know that I still experience the unstable offset. Identifying whether its a harware, driver, setting, or whatever kind of issue is difficult because it isn't apparently what all of the settings actually do -- or if they work correctly to begin with.
Click to expand...
I just checked, and you're right, that bug was never fixed. For that reason, I always use 128 for that parameter. But, I don't know how the average user is expected to know that.

sixtystring said:
All of this is why I try engaging with the forums and with support: so that we can identify these problems and perhaps collectively come up with solutions other than "well it works good enough for me so I don't get why people care"
Click to expand...
FWIW, I didn't take Watt's comment as trying to minimize the severity of the problem. I think everybody's on the same side here :).
 
Yeah, even though I haven't seen the wide fluctuations in latency, the reported latency from the driver is still not correct. I still need a 500+ sample (10+ ms) manual offset with my current buffer settings to get it close. I don't recall needing to use an offset with my Axe II, but it's been a while.
 
I only hope that once this may be fixed, it will also be fixed when used as an aggregate device. My RME is really stable and I'd love to use it together with the AXE and record signals through both interfaces in parallel without any latencies or offsets in one of the units
 
Hi everyone!

There's a lot of great info on this thread and a lot of activity. Thanks everyone for your patience on this. Just wanted to give you guys a little recap of what I've done and maybe some more info on these issues that may or may not be useful.

First, I'll address the title of this thread "Latency reporting to DAW". The USB Audio 2.0 class does support a way for a device to return a latency number back to the computer when requested. I've personally not seen this used by DAWs BUT I've not used every DAW that exists and in fact I'm pretty new to the music production environment. That being said, I'm not sure how this would be useful for our products like the AXE-FX III where any combination of blocks could change the latency and yield that returned value pointless. This method might work well for "vanilla" audio interfaces like the RME since - to the best of knowledge - they are strictly audio interfaces. Additionally, this would not take into account any latency that exists above the audio interface, e.g., the operating system or the driver.

The typical way I've seen DAWs find the latency of an audio interface is to have the user loopback their channels and play a test signal. This is more reliable as it captures the latency of the entire signal chain. Now, in order for this to work the latency has to be repeatable and I think this is the bigger issue here. Once an audio interface is configured - be it and AXE FX III or a piece of RME gear - it should have stable latency. Ideally, the latency shouldn't vary more than one sample in either direction.

Late last year I release a new version of the USB firmware (v1.11) for the AXE FX III that significantly improves the latency. It does not completely resolve the issue but it does offer an improvement. Maybe some of you have tried it and found that it doesn't resolve your issue. But I'll put a link here where you can download it in case some of you haven't tried it yet:
AXE FX III USB Firmware V 1.11

Unfortunately, I had to put further effort into resolving this on the back burner in favor of other priorities. But I want to assure all of you that this is still very much something we are looking into and discussing. If any of you feel like you're being ignored that is probably my fault (still getting used to our forum).

Feel free to continue this conversation or relay any questions to me if you'd like. I'm going to make sure I've got this thread set up so I get notifications when someone posts.
 
amandio said:
Hi everyone!


The typical way I've seen DAWs find the latency of an audio interface is to have the user loopback their channels and play a test signal. This is more reliable as it captures the latency of the entire signal chain. Now, in order for this to work the latency has to be repeatable and I think this is the bigger issue here. Once an audio interface is configured - be it and AXE FX III or a piece of RME gear - it should have stable latency. Ideally, the latency shouldn't vary more than one sample in either direction.
Click to expand...
I remember Cliff told us that in real time processing, the time for processing is bounded by the frequency of the converter. In a 48k sample rate, each process has to finish within 1/48000 second. If the processing take any longer, there can't be real time... Furthermore, the axefx has a grid could add latency... how the hell the column are in phase? Sorry for my rant... back to play guitar! :sweatsmile: :sweatsmile:
 
amandio said:
Feel free to continue this conversation or relay any questions to me if you'd like. I'm going to make sure I've got this thread set up so I get notifications when someone posts.
Click to expand...
I don't pretend to know any answers either, but here are a couple of observations:

1) I think the issue comes down to: How do you explain that other audio interfaces do not have this problem, but the Axe-FX does? An Axe-FX with an empty preset should behave as a generic audio interface. However, even with an empty preset, the Axe-FX shows an alignment discrepancy of hundreds of samples. I'm not aware of any audio interface that has a latency compensation misalignment like that. Even the Axe-FX II is much better than the Axe-FX III.

2) I think you're misunderstanding the magnitude of the discrepancy if you think this is pointless. Typical presets might vary a ms here or there, but the latency compensation alignment problem with the Axe-FX III is typically 10-20 ms. The average new Axe-FX user who encounters this problem is not bothered by an inaudible misalignment of a few samples due to preset-to-preset variations. They are bothered by a very noticeable discrepancy of dozens of milliseconds due to the latency compensation misalignment.
 
amandio said:
Hi everyone!

There's a lot of great info on this thread and a lot of activity. Thanks everyone for your patience on this. Just wanted to give you guys a little recap of what I've done and maybe some more info on these issues that may or may not be useful.

First, I'll address the title of this thread "Latency reporting to DAW". The USB Audio 2.0 class does support a way for a device to return a latency number back to the computer when requested. I've personally not seen this used by DAWs BUT I've not used every DAW that exists and in fact I'm pretty new to the music production environment. That being said, I'm not sure how this would be useful for our products like the AXE-FX III where any combination of blocks could change the latency and yield that returned value pointless. This method might work well for "vanilla" audio interfaces like the RME since - to the best of knowledge - they are strictly audio interfaces. Additionally, this would not take into account any latency that exists above the audio interface, e.g., the operating system or the driver.

The typical way I've seen DAWs find the latency of an audio interface is to have the user loopback their channels and play a test signal. This is more reliable as it captures the latency of the entire signal chain. Now, in order for this to work the latency has to be repeatable and I think this is the bigger issue here. Once an audio interface is configured - be it and AXE FX III or a piece of RME gear - it should have stable latency. Ideally, the latency shouldn't vary more than one sample in either direction.

Late last year I release a new version of the USB firmware (v1.11) for the AXE FX III that significantly improves the latency. It does not completely resolve the issue but it does offer an improvement. Maybe some of you have tried it and found that it doesn't resolve your issue. But I'll put a link here where you can download it in case some of you haven't tried it yet:
AXE FX III USB Firmware V 1.11

Unfortunately, I had to put further effort into resolving this on the back burner in favor of other priorities. But I want to assure all of you that this is still very much something we are looking into and discussing. If any of you feel like you're being ignored that is probably my fault (still getting used to our forum).

Feel free to continue this conversation or relay any questions to me if you'd like. I'm going to make sure I've got this thread set up so I get notifications when someone posts.
Click to expand...
Quite honestly, this is seriously confidence uninspiring that the engineer in charge of the USB audio interface functionality isn't aware that even the basic sub-$50 audio interface handles latency compensation without the user having to take measurements.

In thinking through this problem, it seems best to first address the simplest issue: take the grid and internal processing out of your concerns. When I plug a guitar into input 1 and set my DAW to record on USB input 3, the audio interface of the Axe FX III is no different than a basic $40 Behringer two channel interface - the signal at input 1 is being digitized and passed to the computer without any processing. As it stands, it appears the Axe FX III (or associated drivers) doesn't even attempt to report a latency value for this process where the $40 Behringer does and does so with less than a millisecond of error.

Being able to do that has nothing to do with the grid or internal processing of the Axe FX III.

Turning to recording signals that do utilize the grid/processing it very well may be that this is not doable without some uncompensated latency, and it wouldn't surprise me if reamping the same track twice, with two different grid signal chains (especially if different IRs are used) necessarily leads to some sub-3ms differences in the placement of those tracks in the DAW. Real-world reamping with even slight changes in mic placement will result in similar offsets, so this doesn't seem problematic (nor do I understand why reamping the same track multiple times would be a remotely common practice in recording). As a model for a device that does this kind of thing, the Line6 Helix is an obvious example, as is I think the Universal Audio Apollo line of audio interfaces.
 
Smilzo said:
I remember Cliff told us that in real time processing, the time for processing is bounded by the frequency of the converter. In a 48k sample rate, each process has to finish within 1/48000 second. If the processing take any longer, there can't be real time... Furthermore, the axefx has a grid could add latency... how the hell the column are in phase?
Click to expand...
I'm not saying use of the blocks would add latency. I guess I was trying to describe how having a single, explicit value reported by the AXE FX III as the latency might not be correct 100% of the time due to external variables. Like I mentioned before, this value would not take into account the OS/system latency.
GlennO said:
1) I think the issue comes down to: How do you explain that other audio interfaces do not have this problem, but the Axe-FX does? An Axe-FX with an empty preset should behave as a generic audio interface. However, even with an empty preset, the Axe-FX shows an alignment discrepancy of hundreds of samples. I'm not aware of any audio interface that has a latency compensation misalignment like that. Even the Axe-FX II is much better than the Axe-FX III.
Click to expand...
You're right, with an empty preset it should be stable. In my testing, I configured the AXE FX III as a USB loopback and saw the problem immediately. Just to be clear, the problem I'm trying to resolve is latency jitter. I don't want latency to change more than one sample from run to run. The updated firmware I posted showed during this testing that there was a significant improvement in this regard. It's not 100% resolved though.
GlennO said:
2) I think you're misunderstanding the magnitude of the discrepancy if you think this is pointless. Typical presets might vary a ms here or there, but the latency compensation alignment problem with the Axe-FX III is typically 10-20 ms. The average new Axe-FX user who encounters this problem is not bothered by an inaudible misalignment of a few samples due to preset-to-preset variations. They are bothered by a very noticeable discrepancy of dozens of milliseconds due to the latency compensation misalignment.
Click to expand...
Not saying this issue is pointless. Having your latency jump around is bad. I'm just saying having the AXE FX III return a single, explicit latency value where it cannot factor in external variables could be less useful. Now, it could be that the DAW/OS/Driver/whathaveyou is smart enough to take that value and turn into something useful. I just don't know yet. Also, I'm definitely not shooting down this request. The first thing to tackle is to make sure that the AXE FX III latency is rock solid.
 
amandio said:
You're right, with an empty preset it should be stable. In my testing, I configured the AXE FX III as a USB loopback and saw the problem immediately. Just to be clear, the problem I'm trying to resolve is latency jitter. I don't want latency to change more than one sample from run to run. The updated firmware I posted showed during this testing that there was a significant improvement in this regard. It's not 100% resolved though.
Click to expand...
Oh no! I think there might be a fundamental misunderstanding here. Jitter is not the problem. The problem is: when you record audio from the Axe-Fx, it is misaligned with previously recorded tracks. It might vary a few samples here and there, but there is a large fixed lag of dozens of milliseconds. Nobody cares if it bounces around a couple of samples. All audio interfaces do that. The problem is the large fixed lag. See any of the many threads where this problem has been reported. I believe @Admin M@ understands the problem, so you might want to check with him.
 
Watt McCo said:
Quite honestly, this is seriously confidence uninspiring that the engineer in charge of the USB audio interface functionality isn't aware that even the basic sub-$50 audio interface handles latency compensation without the user having to take measurements.

In thinking through this problem, it seems best to first address the simplest issue: take the grid and internal processing out of your concerns. When I plug a guitar into input 1 and set my DAW to record on USB input 3, the audio interface of the Axe FX III is no different than a basic $40 Behringer two channel interface - the signal at input 1 is being digitized and passed to the computer without any processing. As it stands, it appears the Axe FX III (or associated drivers) doesn't even attempt to report a latency value for this process where the $40 Behringer does and does so with less than a millisecond of error.

Being able to do that has nothing to do with the grid or internal processing of the Axe FX III.

Turning to recording signals that do utilize the grid/processing it very well may be that this is not doable without some uncompensated latency, and it wouldn't surprise me if reamping the same track twice, with two different grid signal chains (especially if different IRs are used) necessarily leads to some sub-3ms differences in the placement of those tracks in the DAW. Real-world reamping with even slight changes in mic placement will result in similar offsets, so this doesn't seem problematic (nor do I understand why reamping the same track multiple times would be a remotely common practice in recording). As a model for a device that does this kind of thing, the Line6 Helix is an obvious example, as is I think the Universal Audio Apollo line of audio interfaces.
Click to expand...
While I'm not new to usb audio (different field of audio in my former life), I am new to music production. I don't doubt that any use cases I've described might be wrong. But that's why I'm here - to learn from you guys.

You're right, in the first setup you mention the AXE FX III should behave like a regular audio interface. My testing shows that my updated firmware nearly gets us there. Again, not 100% resolved but an improvement.
 
Yeah I've currently got a manual latency offset of over 500 samples in place to get it pretty close to aligned when reamping. It is pretty stable at that setting for me, but it's still off from the reported latency by over 10 ms.
 
You must log in or register to reply here.
Back
Top Bottom