The reason for the latency is the use of the USB interface itself.
It’s not suitable for inserts where imperceptible latency is important.
According to other threads in this forum, 8 ms is a perfectly normal value.
As SQuser says, this sounds normal for USB, which is not really suited for (close to) realtime processing.
The optional DEEP processing for the Qu series does not add any latency, but for external processing, the lowest latency possible would be by using a Dante version of the Qu with dedicated low latency hardware (rather than DVS) to get audio into and out of a computer.
It’s not the same range, but the following video talks about Latency in the SQ system and compares different methods of inserting processing including DEEP, USB and Dante to give you some idea of what to expect:
sorry, you are wrong. USB is suitable for low latency. Just look to RME or Presonus. RME do low latency stuff, because they properly wrote their drivers. And Presonus, you can get 2,5ms analog –> usb –> superrrack –> usb –> analog on studiolive mixers (buffer 64), because they focused on this topic. Please, dont lie to your customers and maybe do something with your usb interfaces. Thanks
Just tested pink out of OSM into my QU-5 and straight back for the Ref, then Measurement also through QU-5 –> USB-C –> Live Professor 2 (Mac mini M1 2020) –> no plugins in chain –> USB-C –> QU-5 –> OSM.
I was getting 11.27ms with Buffer 64 / 48k SR and 13.94ms with Buffer 128 / 48k. The quoted LP Buffer alone for 128 was 2.7 ms out of that 13.94ms.
@Keith
It irritates me that you don’t contradict this accusation (even though you were active in the forum today).
Because now it somehow feels like he’s right … ?
Sure - I definitely don’t want to lie to anyone, so apologies, perhaps I should have worded it as ‘the Qu USB interface is not really suitable for external realtime processing’ but whether any USB interface is suitable depends on what you are trying to do and what you consider to be ‘realtime’.
RME have arguably built their name on their custom, kernel level drivers. Which are very low latency for USB and which is one of the reasons they were included in the testing shown in the video I linked to above.
I cannot comment on the Presonus latency as I have been unable to find any roundtrip testing or figures, only the reported driver latency (which would not include other latency, for example overall system latency, which I believe is close to 1.9ms).
Both examples given have built-in low/zero latency direct monitoring options for a reason.
If I take both examples given as fact, they are still not as low as the approx 0.8ms roundtrip latency provided by a Waves server system (not mentioned previously as this is a Qu forum and an SQ with Waves option card and server would be required at minimum), or the DEEP channel processing with no additional latency (meaning only the <0.7ms console latency is in play).
To the point suggesting we should do something with our USB interfaces - the USB hardware was designed for high quality, reliable multichannel capture and playback in mind, it was not designed for running realtime processing. We’ve never suggested it should be used for that and have definitely focused on reliability rather than low latency.
So in short, the latency over USB is fine for capture/playback and also low enough for studio use (especially when you have an ultra low latency direct monitoring mixer built-in). It’s also fine for delay based FX such as Reverb. But for realtime channel processing where low latency is really important, there are other, better, options.
The USB interface itself would be the issue. This is generically a USB issue not specific to Allen and Heath. It’s due to USB driver protocol or something like that.