USB delay test results (reamp via USB)

blearyeyes

Inspired
Using AXE-FX ll MK ll [Quantum 10.1] USB for I/o - Buffer set to 2048 in an Aggregate Device with a Gen1 Focusrite 18i8 into Logic X v 10.4.x (additional configuration information listed in signature)

With a click recorded to a track and sent to the axe fx ll via usb and returning the AXE direct L-R and effected L-R signals which were recorded onto 2 stereo tracks The estimated delay is 16ms direct and 17ms effected in relation to the original click but that was measured using the nudge function set to 1ms and accuracy is not known.

I’m going to do further testing to determine how much delay is attributable to effect processing and if adding more effects on the grid increase delay. (it won’t according to admin but we'll test it)

I’ll also determine if the latency can be compinsated for using Logic's i/o plug-in and if it is configurable/useful for re-amping.

The I/o plug-in reports 1065 samples of delay @ 48k for the effected signal and
970 samples @ 48k for the direct signal

Screen Shot 2018-07-20 at 8.27.53 PM.png
 
Last edited:
Conclusions: Latency varies depending on what and how many blocks you are using. There was no set figure with the exception of all blocks being bypassed and the AXEFX USB direct signal which was fixed at 970 samples running 2048 on the USB buffer in the AXE FX ll. Lower buffer settings rendered lower latency according to the readings generated by the plug-in.

Some of the blocks that were activated after the comp block in the above picture gave differing results. Some even reduced latency readings and the results were varied on some. Whether that was due to the blocks that were activated or other factors is not known.

If there is a way to compensate for latency it will have to be on a patch by patch basis. Any patch switching or scene switching during re-amping will create different latencies. How important that might be to your particular circumstance you will have to determine.

All sample latency readings were generated by Logic's I/o plug-in which sends an audio ping out to the connected unit. It then measures the time difference between the sent and returned audio ping and calculates a latency offset in samples. The accuracy of the plug-in is not known. The round trip latency via USB is determined by factors that might not have been taken into account. So these settings should not be considered as any sort of definitive settings. They are offered up only as examples.
 
Last edited:
Isn’t there a known issue with Logic and Axe-Edit? Not sure if that affects this test at all.
 
I was told that as well by admin but testing seems to indicate that activating / de-activating blocks effects latency
 
Last edited:
The issues I’ve encountered seem to be a combination of Fractal USB Driver, Core Audio and Logic interaction. The way core audio handles midi communication issues, having to use an Aggregate device to get the needed core audio ins and outs to interface the AXEFX with logic in a studio environment and the issue of dropped MIDI communications creates “The Perfect Storm”. As far as I have been able to determine, Core Audio will automatically reconfigure depending on the available i/o it “sees” so when there is a problem with AXEFX USB MIDI communication being dropped, it will change configuration. At this point Logic throws a dialog stating that the amount of available MIDI ins and outs have changed. The USB audio channels remain unaffected. After re-booting the AXEFXll to re-establish midi communication, since core audio cannot query an Aggregate Device, it switches to the Fractal USB driver dropping the Aggregate and passes that along to to Logic causing a driver misconfiguration to occur. The user is excluded from the decision regarding hardware configuration as the dialog presented in Logic only has information. However I know it is possible to change that behavior as Apple’s Mainstage app, in it’s audio preferences, allows you to interrupt the process by throwing a dialog that allows the user to choose the proper hardware configuration. I have been unable to get any information regarding how that might be accomplished other than being referred to the developer resource pages but I am not a programmer. When MIDI communication is lost, USB audio is still present but the reconfiguring effects core audio and Logic as a system. None of this occurs when the AxeFX is excluded from the equation. Dropping of midi communication has occurred with AXE-EDIT running with no other applications IIRC.
 
Last edited:
If I’m reading this right, you’re measuring the time it takes for a signal to get from the DAW to the Axe-Fx for processing and then return to the DAW. To determine latency when reamping. Correct?
 
Isn’t there a known issue with Logic and Axe-Edit? Not sure if that affects this test at all.

I haven’t figured out AXE Edit’s part in all of this other than losing MIDI communication. I don’t believe it has any impact on latency though because it doesn't use audio. Although the combination of MIDI and audio through USB via core audio makes it difficult to say.
 
Last edited:
Having three different layers of OS x/core audio involved makes it difficult to determine what is going on. You have MIDI, AUDIO and USB all with separate software layers interacting. Then you have The AXE hardware/software which uses audio and MIDI via USB. Throw in Logic Pro with audio and MIDI and AXE EDIT which is all MIDI. In between all of this is Core Audio. It’s a wonder this stuff works at all .....and I ever get to write music or play my guitars anymore..:rolleyes:
 
Last edited:
This is good work!
I’ve wondered myself how to “easily” rectify this latency without nudging tracks afterwards.
...some kind of digital clock?
 
It's not a clock issue. It takes time to calculate and process the numbers. Adjusting for latency has been an issue for DAWS from the beginning. The way that it is usually dealt with is to delay all of the non processed audio by the same amount of time it takes for the process to complete.
 
Last edited:
Making good progress. Have a Logic setup and routing that seems to be working out. I'll post a tutorial if anyone's interested?
 
Back
Top Bottom