Helix as audio interface - Round Trip Latency

[zolko60]

This is my elaboration on Round Trip Latency of Helix hardware used as audio interface based on research on closed fb group https://www.facebook.com/photo.php?fbid=10156514192780269&set=pcb.1077888115728194&type=3&theater&ifg=1
This topic is hardly relevant if you are monitoring direct. Helix hardware latency is 1,8ms from AD/DSP/DA (measured for one DSP Path), no matter what buffer or sampling frequency you pick.
If you use another interface for monitoring/recording it is not relevant neither. 
It is 2,70 firmware time.

OSX - you have a choice of two drivers:
1. Multi sampling rate Core Audio driver. You get the lowest latency of 15ms using 32 samples buffer but this seems not to be stable (tested on 8th gen i7) . Safer buffers of 64, 128 samples are at 20ms range.
2. Class Compliant 48kHz driver at 64 samples buffer gives 8ms RTL.
EDIT: I do not know if 8ms RTL is REPORTED by the driver or it can be REAL RTL.

Windows - you have a choice of two drivers:
1. Supplied ASIO driver. Here are my figures for Round Trip Latencies:
21ms on "Small" 128 samples buffer@48kHz
17ms on "Extra Small" 64 samples buffer@48kHz
15ms on "Small" 128 samples buffer@96kHz
10ms on "Extra Small" 64 samples buffer@96kHz - but this setting is unusable because of artifacts.
Bad news for virtual instruments players are 3/4 of RTL is on the output side.
2. ASIO4ALL driver - it is rather overlay for WDM driver, not compatible with Pro Tools.
Round Trip Latencies are:
5ms at 128 samples buffer@48kHz
3ms at 64 samples buffer@48kHz
3ms at 128 samples buffer@96kHz
Good news or virtual instruments players are buffers are 50/50 input/output.
EDIT: I have proven that they are in fact REPORTED RTLs. They are fake numbers!

I made my Windows tests using using Reaper (64bit), desktop Windows 10 PC with 3th gen i5 CPU, 16GB RAM. Reaper session was loaded with 5 Hx Native instances.
CPU usage was monitored with Windows Task Manager and for the same 128 buffers on both drivers was at 30%.
7ms pictured vs mine 5ms is because I switched off additional 32 samples buffers used for latency compensation in ASIO4ALL (for aggregating devices?)

Some pictures to back it up:

[zolko60]

The values of Helix/ASIO4ALL Round Trip Latency were so ubelievably awsome that I had to check them by RTL utility. This utility uses patch cord loopback method.
It came out ASIO4ALL is fooling DAW's with reported input/output latency. But still at 128 buffer, 48kHz Helix/ASIO4ALL measured RTL is 14ms vs Helix ASIO 20ms and significantly lower on 256 buffer (20 vs 34ms @48kHz, 15 vs 36ms @96kHz) 
If 7ms RTL on OSX Class Compliant is true - I want that performance driver for Xmass, please.

Results of Oblique Audio RTL Utility.
Measured RTL (samples)/ Measured RTL ms/ Reported RTL (smpl)/ Reported RTL (ms)/ Driver Buffer / Sampling Frequency

Helix ASIO

0596 12ms 0604 13ms  064 48k
0996 20ms 1004 21ms  128 48k
1651 34ms 1660 35ms  256 48k

0986 10ms 1004 10ms 064 96k
1530 16ms 1548 16ms 128 96k
3428 36ms 2348 24ms 256 96k

Helix ASIO4ALL

559 12ms 192 04ms 064 48k
687 14ms 320 07ms 128 48k
943 20ms 576 12ms 256 48k

1041 11ms 192 02ms 064 96k
1169 12ms 320 03ms 128 96k
1423 15ms 576 06ms  256 96k

[cruisinon2]

OK... I'm not nearly tech-savy enough for this... I need the "Latency for Dummies" translation, lol. From what I can gather, something is good, something else is bad, and there may or may not be some other thing that's lying. 

 

That about right? ;)

[zolko60]

20ms Round Trip Latency in 2018 is a joke. 2003 plastic USB 1.0 2in/2out Digidesign Mbox 1 used to have 25ms.
Look at old Dawbench tests. I am sure Line6 can do better. Helix is awsome hardware.
https://www.dawbench.com/audio-int-lowlatency2.htm

[sat_chY]

Hi Guys I just got the stomp as I had used the pod x3 live and guitar port I usually play through my pc with music and noticed this huge latency with line in using either headphone jack or mono out from stomp 

I was thinking I could just use a pac speaker but then thought if I want to record I still need to use it this way

Is there anything I can do to bring my latency down? Im on windows 10

Im not using any software just straight line in and ther line 6 driver

 

I don't remember the guitar port having such latency 

 

Cheers 

Lee

[zolko60]

On 12/3/2018 at 6:28 PM, zolko60 said:

This topic is hardly relevant if you are monitoring direct. Helix hardware latency is 1,8ms from AD/DSP/DA (measured for one DSP Path), no matter what buffer or sampling frequency you pick.

While recording with Hx Stomp you do not need to hear your DI signal. All you need to hear is processed by DSP signal. Output latency of monitored prerecorded track is irrelevant.
Please vote!
https://line6.ideascale.com/a/dtd/Low-Latency-driver-for-Windows/945091-23508?submitted=1#idea-tab-comments

[njglover]

A lot of the issue is tied into USB 2, I suspect. So hands are kinda tied there. CPU is also factor and a 3rd gen i5 is what, 4 generations behind now? Truthfully, to bring latency down much more it would probably need to be USB 3 or C and that would require a complete hardware revision. So yeah, maybe the driver could be updated to bring it down to the levels you are seeing with ASIO4ALL but... probably not much more beyond that.

 

For example, look at comparable (8 in/8 out USB) interfaces in the article you linked to. The Focusrite Saffire 6 USB is only a few ms lower than Helix, others are maybe a little faster than that but still not any faster than your ASIO4ALL results. That's just the limits of the technology. That's why interfaces always include a direct monitor option. It's certainly not ideal if you are trying to monitor with Native, but that's just the way it is. Rather than worry about round trip latency of Helix (which, as you say, is moot anyway since you can monitor your effected signal on the device), if the goal is to use Native than pick an interface better suited for that. USB3 or Thunderbolt, for example. There's simply no pressing need for Helix to have lower latency.

[zolko60]

CPU can be a factor of course. 64 smpls@96kHz buffer which is useless on my 4 core i5 can be usefull on 8 core/16 threads i9. However it is still 11ms RTL on the same driver. My idea of improvement is to consider driver revision to find out if lowering its latency to OSX Class Compliant driver range is possible. I am assuming that 8ms RTL 64smpls@48kHz is correct and playable on any modern Apple device.

ASIO4ALL is not any reference. It is only overlay for WDM driver supplied by Line6. It can do no more than WDM driver allows for. ASIO4ALL can however report fake RTL figures to ASIO based DAWs. It's seems not to "know" much of Helix additional USB buffer and AD/DA latencies.

2012 results are not the reference neither. From that time a whole bunch of newer USB 2.0 were produced with RTL timing in 3-10ms range.

[njglover]

If I recall, WDM drivers typically have lower latency because they operate at an OS level. Same with Core Audio drivers on OS X.

[codamedia]

IME... any modern CPU is capable of low round trip latency. My home studio still runs on a Quad Core "pre i series" CPU.... I don't have problems with latency unless I set my buffers too high. Chipsets and their associated drivers (motherboard firmware) are a much bigger culprit. I have also seen video card drivers/settings disrupt audio latency, network cards and I've even seen latency change from DAW to DAW on the same machine. 

 

I can go to any forums for any audio interface.... there will be a dozen or so people struggling with latency and a bunch of others saying they don't have any problems. It's not always the device and it's driver... it's a combination of 100 other things that can effect it as well. 

 

Just my experience and two cents on the subject! 

[zolko60]

Indeed. There are machines suffering from various issues like high DPC latency. Sometimes there is a need to isolate and update driver that gives high DPC spikes. What I am writing about are properly configured and optimized for audio use Windows machines. They happen to have replicable RTL figures.

People do care. 7 years lasting thread:
https://www.gearslutz.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html

[zolko60]

How can I confirm my RTL measures are right or how you can check it without any special equipment?
1. Let's take any DAW (in my case it is Pro Tools 12 HD) set Helix ASIO driver to 64 samples buffer 48kHz
2. Let's make a new Hx preset with Path USB3/4 input USB 5/6 output, FX Loop in beetween (preset attached) RTLcheck.hlx
3. Let's make two tracks: 
First (named DI) with 7 input (default Hx guitar DI out), 3 output
Second (named RTL) with 5 input, 1/2output (default mixed to Hx Multi Out)
4. Connect guitar to guitar input and record
5. Measure the offset of two recorded tracks.
What I get here is about 512 samples (10.6ms). It is RTL when no AD/DA conversion is measured (AD/DA conversion latency is present but the same in both cases and not "visible")
This is usefull knowledge when you do reamping with Helix - 510 samples should be the offset to align reamped track with DI.
If I switch FX Loop on (via patch cable) i get 600 samples (12.4ms). This is exact value of reported, measured by Utility RTL value. Additional AD/DA latency is 90 samples (1.8ms).

[stevenew]

Latency using a Aggregate Audio Device of Helix Floor and MOTU 624 on my 4.1 (flashed to 5.1) Mac Pro 2 x 3.46 GHz 6-Core Intel Xeon, Mojave 10.14.2

 

As I use a lot of VI and sample libraries 44.1k & 48K are really the only sample rates that are practical.

 

Do I just add the In & Out to get a total RTL?

 

Cubase 10 & 9.5

Aggregate Audio Device of Helix Floor (Line 6 Driver) and MOTU 624

44.1K   64 = In   7.438 Out   9.433 = 16.871

44.1K 128 = In   8.889 Out 10.884 = 19.773

44.1K 256 = In 11.791 Out 13.787 = 25.578

   48K    64 = In   7.333 Out   9.333 = 16.666

   48K  128 = In   8.667 Out 10.667 = 19.334

   48K  256 = In 11.333 Out 13.333 = 24.666

88.2K    64 = In   9.705 Out    8.707 = 18.412

88.2K  128 = In 10.431 Out   9.433 = 19.864

88.2K  256 = In 11.882 Out 10.884 = 22.766

   96K     64 = In   9.667 Out   8.667 = 18.334

   96K   128 = In 10.333 Out.  9.333 = 19.666

   96K   256 = In 11.667 Out 10.667 = 22.334

 

Helix Only with Line 6 driver

 

44.1K   64 = In   7.438 Out   9.433 = 16.871

44.1K 128 = In   8.889 Out 10.884 = 19.773

44.1K 256 = In 11.791 Out 13.787 = 25.578

 

Aggregate Audio Device of Helix Floor (class compliant) and MOTU 624

 

48K    64 = In   4.583 Out   3.354 = 7.937

48K  128 = In   5.917 Out   4.688 = 10.605

48K  256 = In   8.583 Out   7.354 = 15.937

 

Helix Only with class compliant MacOS driver

 

48K    64 = In   4.583 Out   3.354 = 7.937

48K  128 = In   5.917 Out   4.688 = 10.605

48K  256 = In   8.583 Out   7.354 = 15.937

 

 

MOTU 624 Only

 

44.1K   64 = In    1.995 Out   1.995 =   3.99

44.1K 128 = In    3.447 Out   3.447 =   6.894

44.1K 256 = In    6.349 Out   6.349 = 12.698

   48K   64 = In    1.833  Out   1.833 =   3.666

   48K 128 = In    3.167  Out   3.167 =   6.334

   48K 256 = In    5.833. Out   5.833 = 11.666

 

Using the same Cubase project, the aggregate device at 48K using the Helix on class compliant gives a much better latency but the CPU hit is much higher than using aggregate device at 48K using the Helix Line 6 driver with the same buffer size…

Using the MOTU on its own with the same sample rates and buffer sizes not only is the latency way lower the CPU hit is considerably  lower. I am seriously thinking of getting a converter so I can take the Helix SPDif coax out to the SPDif optical in on the MOTU and run at 44.1K 64 or 128 buffer. Super low latency and minimal CPU hit.

 

Hope this is useful

 

[zolko60]

Thank you!
I see Motu interfacing and latency performance is just like my dream of Helix II. (Who knows, maybe AVB, Dante, AES67 are compatible already?)
Still there are cheap USB2 interfaces on the market with similar RTL performance.
I just hooked up my 2003 Digidesign Mbox 1. At 128 samples buffer @48kHz 20ms RTL - the same perfomance as Helix ASIO at the same settings.

8 hours ago, stevenew said:

I am seriously thinking of getting a converter so I can take the Helix SPDif coax out to the SPDif optical in on the MOTU

There are cheap SPDIF RCA to SPDIF optical converters on the market. AES/EBU (present in HxF, HxR, HxLT) can be easilly "converted" to SPDIF by using XLR to RCA cable with cold NOT CONNECTED to ground/shield. Always worked for me.

[zolko60]

Nice chat on the topic in closed fb group https://www.facebook.com/groups/line6helixusergroup/permalink/1489385381245130/
Line6 employee claims nothing latency wise has changed with 2.9X firmware. Some people report RTL about 6-8ms on OSX at buffers sizes 64 and 32 samples.
If anybody can confirm 32 (OSX) and 64 smpl buffers to be usefull (artifact free) please share your RTL reports or measurements and CPU model.

Thank you for your cooperation!