QC numbers report (latency, send levels, etc.)

Since none of these numbers are mentioned in the documentation, I thought we should have a report post concerning latency, levels and maybe more.

So far I discovered that :

  • Using Rows 3 & 4 adds 2.5ms to the latency was true with CorOs 1.4
  • Using the Send/Returns adds 2.5ms to every conversion (Digital to Analog and Analog to Digital) was true with CorOs 1.4
  • The Send Output is 4.5db louder than unity gain when using a TS cable. Still true and tested here for CorOS 2.0.0

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.

If everyone agrees with the numbers, I will leave them as…
If anyone disagrees, let me know and I will modify the RECAP.


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.


Just redid my Pings (via Logic Pro, I/O Plugin that lets you do pings & gets samples back)
USB 5 input, USB 7 output…

Here are my measurements :

How did you measure the numbers you have ?
Maybe we can define a method… Use the same process.

BTW it is weird that adding a splitter between Row 3 and Row 4 adds that much latency while rows 1, 2 & 3 behave nicely.

Is it a lack of optimisation or is it some other cause ?

If an @MP_Mod could clarify…

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?

Funny thing I just tested with Row 3 :

  • Row 1, put a gain block from the utility : measured 1,75ms latency (nothing added to the base latency)
  • Set the output of Row 1 to Row 3, then drag the gain block to Row 3 : measured 4,42ms

It seems that Row 3 doesn’t induce latency until a block is on its line.

It all confirms what I’ve been doing lately : avoid Row 3 & 4 when playing tight stuff or to a click…

Thanks @PeterO for playing the “what’s happening under the hood” game ! :wink:


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?

Does that program/setup account for the latency of your computer/audio interface as well?

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.

1 Like

Here is what I measured :

From here we can say that

  • Row 3 adds latency (2.67ms) if used with blocks
  • FXLoops add latency (1,85ms) due to the Analog to digital conversion when using the Return.
  • An FXLoop on Row 3 is the latency super-bundle (7.19ms)

These measurements are done with either a Gain Block OR an FXLoop Block, not both at the same time and with no other Block on the chain.


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)

1 Like

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)

And now for the Send/Return volume differences :

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 :slight_smile: ) 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.

1 Like

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.

@MP_Mod ? (can’t mention ndsp_staff)


It’s a feature request now :

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.

1 Like

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.

That’s some serious optimisation from NDSP :