Low Latency Mode (and power mode?) for QC

I was so curious now that I made some measurements. I’m quite sure they give the right tendency, even if they are not perfect.

First result:
I was wrong, latency depends on CPU load of the QC. This is in line with @MortenRL 's observations. And this might explain why some people are complaining and other aren’t.

Then, here’s the measurements:

CPU Load 5% (empty preset)
2ms latency

CPU Load 20% (my simplest preset)
4ms latency

CPU Load 40% (my most complex preset)
7ms latency

CPU Load 85% (artificial preset, I just put a lot of different blocks to get as high with the load as I could)
13ms latency

So it’s actually quite linear. For me, it’s no problem, as I never use more than 40% CPU. But I can understand that for others, it might be a problem if you max out the CPU.

Results seem quite in line with @danimaetrix saying that max latency with real-world presets is around 10ms.

By the way, it did not make a difference if I bypass the blocks or not. Bypassing does not change the CPU load and does not change the latency. Only removing blocks will reduce load and latency.
And it also did not make a difference whether the load was on one core (rows 1 and 2) only or split between the two cores (split between rows 1/2 and 3/4). Latency remained the same and was only depending on overall CPU load.


Hi everyone. My main preset is pretty heavy on CPU (around 65%) and I do not feel any latency. Maybe is because I am used to playing through my computer/DAW in my studio over many years, and I got used to some latency?

I’m not using the QC as an audio interface. Just connecting the QC outputs directly to amp or PA, or into an input of my Apollo Interface.

I gig the QC live on a weekly basis both using in-ears and also with a real amp. I have other small issues with the QC, but Latency is not one of them.

Keep in mind that up to 5 ms. of latency should not be perceptible.

1 Like

Latency isn’t the end all be all thing it’s made out to be either. Everyone perceives it differently, and also just having high CPU % doesn’t mean it will be higher latency. I think it’s more about routing, ordering, and specific types of FX. That and I’m also used to playing far away from a cab, which by itself contributes more latency than most modelers have in total.


@danimaetrix @legzalez

I think it reeeally depends on what ur playing. For anything gainy I don’t mind it. But when I’m paying more subtle rhythmic clean stuff where you hear the transients very clearly… That’s when it throws me off.

Try to limit the signal chain within 1-2 row only.
I made test and found once I enable row 3-4 latency will be at least increase 2ms+
Official explains this due to row 3-4 Will activate 2nd core of CPU

1 Like

you can use reaper and reainsert to measure it if you’re really curious

Any thoughts on this analysis? This is an interesting conversation.

I did not see more than 13ms latency, so I’m a bit surprised about the 23ms in the video.
And I also think I would feel the 23ms, if any of my presets would have this kind of latency.

1 Like

Also, the 24ms was with 5 captures… I’m not sure I would ever be using 5 captures simultaneously.

Me too. Assuming the results are correct, 23ms is absolutely in the realm of creating a softer, less responsive, more spongey feel. Neural needs to work on reducing this in future updates if they haven’t already. This video is about 6 months old so latency test numbers might conceivably be better since the latest update.


Ok, so I finally got to do some testing.
The preset in question uses 40% cpu and is probably near as much as I’ll ever need. I realize that cpu usage isn’t the only factor relating to latency, but I’m still using it as an indicator.

The result:
Everything bypassed (including amp and cab): 7,2ms

Scene 1 (5 blocks engaged):

So at 40% we’re already at a point where the latency is nearly 8ms. Which means that 60% of the QC’s capacity is as good as ununusable for people like me who are a bit sensitive to latency.

Unless the QC functions totally unlike a computer (which I doubt), there should be a way to reduce the buffer size, so that more than half of that processing power can be put to better use… Someone more techy than me are welcome to tell my why I am wrong :grin:

So can I reduce the latency of that preset?
Now, by removing three blocks (which in itself takes it down to 6,58ms) and moving everything away from row 3/4 I was able to get down to 4,145ms, which is much more acceptable. So yes, one could compromise and do workarounds but, the selling point of the unit is it´s power and flexibility. One really shouldn’t have to…

And that concludes todays prayer :pray:


I like that the OP is thinking out of the box while recognizing that “making the QC more efficient” is the way to go. While @MortenRL does propose an innovative workaround, grabbing half the processing power to solve the latency issue may not be a good way to approach this. Offering this proposed “efficiency” mode might have the unintended consequence of encouraging the writing, or persistence, of inefficient code that has not been properly optimized and slowing delivery of better code. To me this is like saying, instead of developing a more efficient mode of transportation, let’s just keep everything parked.

Frankly the last thing I want is to give up a significant portion of processing power, which might include way fewer blocks, or having to exclude more complex and resource intensive amps or effects from the signal chain. IMO this is a terrible way to go about things. The code needs to be optimized going forward so that latency is lowered while leaving the ability to have long and/or complex signal chains intact! All the other major modeling companies have managed to pull it off. If, after optimization is delivered, they want to provide this option for users who value super low latency over flexibility in their signal chain, I think that would be a grand idea.

1 Like

I agree that optimizing is the way to go!

My point is that until Neural gets there, this would be a nice temporary solution (emphasis on temporary). And as soon as they are there, it would take on new life as just a nifty feature.

Considering the “most powerful” slogan, I think being able to achieve super low numbers would be great for marketing as well…


Ok, so after some back and forth with support, this is their reply after sending my results:

“When you’re using the QC as a modeler, the round trip latency is usually between 2 - 5 ms, which is unnoticeable by the human ear. Even 7.8 ms is unnoticeable.
The latency inherent to the QC is the value mentioned above. Any additional latency will come from external sources.”

To which I cannot even…
For reference, this is 7.8 ms of delay. It´s not an “echo” of course, but there is no way that´s “unnoticable”. If you´re trying to be right on the beat, but you´re that much behind or in front… That makes a difference. Even 5ms is perceivable as separate transients. When we´re getting down to 4ms, the transients start to become indistinguishable.

Also blaming external sources is such poor taste. I´ve made it clear that there are no external sources (guitar → cable → QC → passive in-ears).

I´m not expecting anyone to fix the issue this instant, but for support to just flat out deny that it´s a potential issue… Well, it´s dissapointing. Hoping to see some unexpected improvement in 2.0…


@MortenRL it’s very subjective, so I guess it’s difficult to find a common opinion.

7ms equals around 2m of distance from a speaker. I often have this when playing live and I have no problem playing like that.
When I use headphones, I find the same latency irritating, for whatever psychological reason.
I imagine that people more sensitive than me will have even more problems.

I don’t agree with Neural’s statement that the maximum is 5ms, I have measured much more and, as you, I can quite exclude external influences.

So, for me it’s not an issue, but I understand if it is one for you and I believe it could be optimized.


Just for the record, latency and DSP are not directly proportional. You can use a lot of DSP and still have lower latency, just like you can get higher latency with less DSP. It’s more about specific items and how you’ve routed the grid than it is about total power. I noticed a custom IR that was introducing nearly 20ms or more all by itself, for example.

The average I see is around 5-12 for most presets I’ve built (many with a lot of row splitting). Each FX loop adds 2-3ms by itself even disabled, so that’s another thing to keep in mind.

1 Like

Yup, I understand that it’s not directly proportional.

For example when testing, I discovered that removing one out of three different delays did very little to the latency. Removing two made a little bit. But then when you remove all three it suddenly drops considerably. This seemed to be the case with other “groups” of fx as well.

one thing I’ve noticed is you probably need to set mix level on those to zero or something to measure that, or bypass if it doesn’t affect latency. Otherwise you’re probably confusing the measurement instrumentation because of the actual delay effect? Not sure if true, just a thought

Does a FX Sent Block (that is never receiving anything) add Latency?

I measured a 2.54ms latency on an FX Loop with a patch cable between Send & Return.

It’s the DA conversion to Send and AD conversion to return that adds latency.