This post is not intended for criticism, it is meant to gather factual numbers for documentation.
If anyone has more information, please join in and share.
** EDIT ** These measurements are outdated with CorOS 2.0.1. New ones here and here and here
** RECAP **
The QC has a base latency of 1.75ms (1 row + no blocks)
Row 3 (if used with a splitter or a block) adds 2.67ms to the base latency
An FXLoop (if used on rows 1 or 2) adds 1.85ms to the base latency
An FXLoop used on Row 3 or 4 ( Send/Return + row 3 latency) adds 7.19ms to the base latency (@PeterO found 9ms of latency)
The Send level of an FXLoop is 4.5db louder than unity gain
The Return level of an FXLoop is 0.1db louder than unity gain
These numbers were measured using the QC as the single audio interface, USB 5 In, USB 7 Out + Logic Pro’s IO Plugin (external hardware insert plugin to measure external latency)
For anyone doubting this : if there was any computer induced latency added to the numbers, we couldn’t get the 1.75ms base latency number. That number would have to be higher than the roundtrip value due to the buffer size.
I’we done some measurements too and my results are a bit different.
From analog input to analog output, using no blocks, I measure 1.86 ms of latency no matter how many rows I’m using. This is with firmware 2.0.0. With firmware 1.4 I did see and increase in latency (approx. 1.8 ms) when adding row 3/4 to row 1/2.
Using a send+return adds another 1.86 ms of latency.
An amp capture together with a cab block adds approximately 1 ms.
Most of the effects adds latency and with my most “crowded” presets I end up with around 8 ms of total latency.
My measurements are done with a program called RTL Utility from Oblique Audio.
I’m measuring the round trip latency using analog ins and outs. That being said, it seems that our measurement does not differ more than 0.2ms. That’s probably the time the AD and DA conversion takes. The rest of the latency is caused by buffering.
I just did the “all four rows” test and can confirm that the latency jumps from 1.8ms with 3 rows to 4.5ms with 4 rows. That is really strange and if it’s not just caused by a bug in the device, I would love to know why it is happening?
I think I know what’s going on - or I have a guess:
Processing of blocks in row 1 and 2 is done by one core and processing of blocks in row 3 and 4 is done by another core. Buffering of data is needed when data is passed from one core to another and that causes latency.
When there are no blocks to be processed by the core assigned to rows 3 and 4 the code is optimised to simply skip the transfer of data to that core. But in the code a split is also just a block. So adding a split to row 3 causes the data to be send through and processed by the 2nd core, with the added latency as a result.
But I can’t understand why the utilisation of a second core adds 2.7ms of latency when the total round trip latency is 1.8ms when only one core is utilized?
And the plot thickens …:
I just did a measurement with a gain block on row 1, the output of row 1 set to Send 1, the input of row 3 set to Ret 1, a gain block on row 3, the output of row 3 set to Out 1/2. I expected the result to be the 4.5ms we’ve seen with rows 1 and 3 in use + the 1.8ms I’ve measured earlier that an effects loop adds to the total latency, but my measured latency is 9ms! That makes absolutely no sense to me!
I have done another measurement with the same setup as above but using an effects loop block on row 1 and that give me the expected 4.5ms + 1.8ms = 6.3ms of latency.
I then moved the effects loop block to row 3 and that gives a total latency of 9ms! That can’t be right?!
@thomasotto could you please replicate these tests and let me know if you’re getting the same results?
No it does not. I first do a measurement with a cable inserted between an input and an output on my audio interface to get the round trip latency of my computer/interface and that number is then subtracted from all subsequent measurements.
So, it seems that QC has THE WORST latency of any modern digital Multi-FX units out there.
Does @ndsp_staff or someone from NDSP have any interest of commenting these findings?
From what I remember reading and also seen Doug Castro saying in interview: QC should have 3ms Latency… but it looks like, that nobody told it gets much worse if you want to use all the power, that QC has to offer.
The IO plugin in Logic Pro is an insert plugin for external hardware. It has the ability to Ping (send a click then measure the delay in samples) to compensate for the hardware’s potential latency.
All I use it for in our scenario is to get the latency of the QC.
Here, the QC is the only audio interface linked to my computer (to get the most accurate result without another audio interface potentially putting confusion on the numbers)
Well, I guess NDSP is right about their sub 3ms latency on the QC (1.75ms with 1 row and no blocks)
Our main issue as users is the variable latency when using such and such Block or Row.
I’d recommend staying on two lanes (Rows 1 & 2) and avoiding external inserts (FXLoops)
I guess it all depends on the type of sound I’m after :
If I need a mushy atmospheric sound then I don’t really care about latency.
On the other hand, if I’m Chicken Picking or playing tight funky single lines or on the “grid” Afro Rhythm parts, then its a patch with minimum rows and no FXLoops.
I think it’s important for users to start measuring their patches when something feels off (with Logic Pro’s IO plugin for mac users or RTL Utility from Oblique Audio for PC/mac users)
And, for anyone using the “1 meter away from amplifier” argument : I do use and amplifier… On top of the latencies measured so, yes, every millisecond counts (for me anyway)
It seems that the Send is boosting the volume by 4.5db (I read the numbers below on the I/O Settings page, ie the mixer of the QC, assuming they are accurate)
It seems also that the Return is boosting the volume by 0.1db (kinda irrelevant but… for accuracy’s sake)
So for people wanting exact unity gain on their FXLoop, turn down the Sends by 4.5db, turn down the Returns by 0.1db and you should be there.
The method :
QC as the only audio interface via USB
Sine wave generator set to -12db on input set to USB 5
Insert the FXLoop 1 block on Row 1
Insert a patch cable between Send 1 & Return 1
Output set to USB 7
Swipe down on the QC screen to get the I/O Settings
Click on USB and verify -12db is coming in and going Out (shouldn’t be at this point)
Click on Send 1 and verify that you get -7.5db level
Turn the Send level down by 4.5db
You should now have -12db on the Send
Click on Return 1 and verify you get -11.9db level
Turn down the Return level by 0.1db
You should now have -12db on the Return
Now click again on the USB icon and expect to have -12db In and -12db Out… right ?
Why am I getting -12.1db on the USB 7 Output now ?
Are the meters accurate on the I/O Settings ?
I know this is splitting hairs but still, I’d expect digital accuracy from the QC.
Well, anyways, as I said in my first post : factual numbers !
The latency of my presets (8 ms or below) is not enough for me to be bothered by it (I’m a sloppy player anyway ) so this is all a bit academic for me.
It’s not a surprise to me, that using more than one physical core results in an increase in latency, but it is surprising that it’s 2.5ms rather than the 1.8ms “basic” round trip latency.
It’s even more surprising that using rows 1 + 3 and adding an effects loop to row 3 result in 9ms latency, and that’s before any blocks/processing is added!
I’m guessing that a preset using an effects loop in row 3 or 4 and a healthy number of blocks on top of that, will result in a total latency that is noticeable even by me!
But again this is all academic to me and I’m still very happy with my QC and the sounds I’m able to get with it.
a pedal board with this power cannot have these problems !!! I also encountered big latency problems and loop unity gain problems!! and it is very serious that Neural does not say or do anything about it! I am very angry if they don’t fix it I will be forced to sell it
I would rather see a Preset Latency Monitor than a CPU Monitor in the top right hand corner.
It would help us all in making choices and slimming down the grid if necessary.
Also, that CPU percentage is calculated for all rows. Kinda confusing when it (hypothetically) says 50% and you can’t add anything to Rows 1 & 2.
Or even better : an advanced menu where one would choose the buffer size (the latency).
If audio cracks, slim it down or up the buffer.
Basically like in any recording studio.
All, this has been forwarded to support. Thanks for the feedback!
For the future, please remember to email support@neuraldsp.com so that they can log, track your issues and provide diagnostics until resolved.
Started measuring Block latencies (the stuff I usually use) and was flabbergasted !
Same method : QC as the only audio interface via USB + Logic Pro IO plugin to measure outboard hardware latency, USB 5 In and USB 7 Out. One block at a time on Row 1.
) so this is all a bit academic for me.