zolko60

(BEWARE IT IS A JOKE)
All you nedd to do is to write a quirk, put the following lines into quirk-table.h and recompiled. :D :D :D

/*
 * Line6 devices
 */
{
    USB_DEVICE(0x2466, 0x8003),
    .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
        .vendor_name = "Line6",
        .product_name = "Helix",
        .ifnum = QUIRK_ANY_INTERFACE,
        .type = QUIRK_COMPOSITE,
        .data = "" (const struct snd_usb_audio_quirk[]) {
            {
                .ifnum = 0,
                .type = QUIRK_AUDIO_STANDARD_MIXER
            },
            {
                .ifnum = 1,
                .type = QUIRK_AUDIO_FIXED_ENDPOINT,
                .data = "" (const struct audioformat) {
                    .formats = SNDRV_PCM_FMTBIT_S24_3LE,
                    .channels = 2,
                    .iface = 1,
                    .altsetting = 1,
                    .altset_idx = 1,
                    .attributes = 0,
                    .endpoint = 0x02,
                    .ep_attr = 0x05,
                    .maxpacksize = 0x002a,
                    .rates = SNDRV_PCM_RATE_CONTINUOUS,
                    .rate_min = 48000,
                    .rate_max = 48000
                }
            },
            {
                .ifnum = 2,
                .type = QUIRK_AUDIO_FIXED_ENDPOINT,
                .data = "" (const struct audioformat) {
                    .formats = SNDRV_PCM_FMTBIT_S24_3LE,
                    .channels = 4,
                    .iface = 2,
                    .altsetting = 1,
                    .altset_idx = 1,
                    .attributes = 0,
                    .endpoint = 0x86,
                    .ep_attr = 0x05,
                    .maxpacksize = 0x0054,
                    .rates = SNDRV_PCM_RATE_CONTINUOUS,
                    .rate_min = 48000,
                    .rate_max = 48000
                }
            },
            {
                .ifnum = 3,
                .type = QUIRK_MIDI_STANDARD_INTERFACE
            },
            {
                .ifnum = -1
            }
        }
    }
},
https://www.spinics.net/linux/fedora/alsa-user/msg10927.html

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.

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

Low Latency driver for Windows
 

Current (2.70 firmware) version of ASIO driver for Windows is in 10-36ms Round Trip Latency range.

https://line6.com/support/topic/37727-helix-as-audio-interface-round-trip-latency/

Helix hardware is awesome sounding audio interface and deservs low latency driver in 5-18ms range (for the same buffer sizes)

Please vote!

Try to swap USB cable. The supplied ones sometimes do not work properly with particular USB chipsets (ports).

EDIT: I checked. 2017 MacBook Pro has two USB-C ports, so why use any hub which causes problem? All you need is to stick right USB cable.

On 9/30/2018 at 9:20 PM, silverhead said:

Has anyone tried using 2 instances of Helix Native in their DAW to simulate a doubling of the DSP?

Yes, I have. Like with all plugins you can use as many instances as your CPU can handle in any configuration - serial, parallel, looped... but I think it does not make sense. If you work with DAW you have almost unlimited number of other plugins IR loaders , reverbs and so on. So you can easilly override any HxN limitations.
5 instances Hx Native use about 30% CPU power of old 3gen 4 core i5 with 10ms Round Trip Latency (vs one instance on Dual DSP Hardware Helix at 1,8ms)

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

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

1. How did you record DI track?
2. How reamping path looked like?
3. How IR was captured?

You can also join the fb group and ask there. You never know who you can find there ;) 
https://www.facebook.com/groups/line6helixusergroup/?fref=nf

I would take a support ticket for that, but I recall adapter from 48V Phantom to 6V battery powered mic made of Zener diode and two resisors or little more complex P48 to T power ed (12V) mics also Zener based.
Hope that helps.

I would get a Tech Support ticket for that. I have used it only once so far, but information was helpful and not published anywhere else.
By the way - if you think such info should be a part of Specification, please vote and add your comment.
https://line6.ideascale.com/a/dtd/Specifications-publishingof-I-O-imedances-FS-levels-etc/943915-23508#idea-tab-comments

1 hour ago, PeterHamm said:

Well, it matters not a whit to me, as I use it with a DI anyway and like that solution.

Well, it matters to me and several other people writing in several threads on this forum.

1 hour ago, PeterHamm said:

The fact that the TRS to XLR cable changes the signal might not be because it is balanced. Something else could be going on perhaps?

I don't know anything about that "fact".  XLR or TRS is just a type of connector. It does not change anything but interfacing option.

1 hour ago, PeterHamm said:

I don't know,  to be honest. Someone from L6 might have to chime in, but it's not really a performance issue is it?

Line6Will stated it officialy in the link I have posted. It could be performance issue when you trust the owner manual and do not take advantage of CMRR impedance balanced out gives you.

OK. Some of your sources missled you. So what is the reason for insisting this is the case when it is sorted out? You can even pull out your ohmometer and check.
Again - there are no specifications for 1/4" outputs in the manual. You can clearly check it with no eqiupment by reading the manual.

1 minute ago, PeterHamm said:

 Line 6 has confirmed that the only balanced inputs or outputs on any Line 6 HX product are the Mic input on Rack/Floor and the 1/4" outputs on Stomp.

What are you reffering to? What knowlege sources?

To be honest I don't know:
1. Why the author of the manual does not want users to take advantage of CMRR of impedance balanced outputs.
2. Why he/she is calling 20ms RTL drivers "low latency".
3. Why the are no specifications there.
4. Why resolved questions do not come to later manual editions and knowledge base.
BTW: Please vote https://line6.ideascale.com/a/dtd/Specifications-publishingof-I-O-imedances-FS-levels-etc/943915-23508

8 minutes ago, phil_m said:

 

All the 1/4” outs on the Floor, Rack and LT (and HX Effects) are unbalanced. It’s been confirmed by Line 6 many times, and it’s in the manual. The 1/4” o7ts on the Stomp are balanced.

What makes you write that?
There are no specifications in manual. There is only cable use recomendation there for 1/4" outputs.
One and only spec published by Line6 states outputs are impedance balanced.

Yes, I mentioned OP behavior (sorry, I needed to check what OP is. English is not my mother's tongue). Did I offended him? Is any comment on some test are relevant to my reflection?

Well, for me it is really useful test. This is how customers test, compare and use their products. If you happen to have Kemper with the super duper impulse bought for 10$ and every other Kemper user claims this is THAT impulse made of THAT amp on THAT guitar, recorded thru THAT same recording path and used for THAT Top 10 record - all you want to hear is THAT sound after you connect it to the monitor you bought.
Istead you are cofused and have to ask on some forums what is wrong and treat the advice of checking your tweeter as "toxic" or offensive.

5 minutes ago, rd2rk said:

(...)why use the TS312 instead of the HR FRFR112? (...)

Because nobody ever proved this is different product except of logo, blue diode and lack of mic preamp.  People who compared them side by side claim there is no difference in sound.
BTW: This is not scientific test.

Indeed!!! 2.10 Manual page "TIP: Press PAGE> to view and turn Knob 1 (Apply EQ) to set whether Global EQ is applied to only the 1/4" outputs, only the XLR outputs, or both."
Sorry for misleading.
So we are saved!!! :D

Sorry to read that. The mobile 2nd gen i3 CPU, 4GB RAM should be fine on 128 buffer on decent modern interface with 3-7 latency. If it is not either hardware or driver sucks.

If I have something messed up, what gives me artifacts, switching to the supplied high latency driver is easy. I hate ASIO4ALL but for low latency Helix operation under Windows it's a must.

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:

It is definetely a matter of EQ'ing your FRFR to be Full Range Full Response. Albeit Global EQ in Helix works for all analog outputs,  so to get similar sound, FOH engineer would have to use reverse EQ.
In this shootout Alto/Headrush bass response is compared with other FRFRs