Low Latency Mode (and power mode?) for QC

[MortenRL]

Low Latency VS Processing: Sport, Normal (and Power) Mode

(Before anyone asks: No, there is no latency in my monitoring )

The QC needs a Low Latency mode. Latency is my single biggest issue with the QC. There are many scenarios where it´s low enough to not be an issue, but in others (clean funk plucking, for example, especially live with a drummer) it becomes painfully obvious. If nothings happens with latency I sadly won´t hang on to my QC.

Lowering the latency all together by making the QC more efficient would be the best solution, obviously, but I realize that it´s challenging.

An idea for a fix, or at least a partial fix:
My main preset uses about 50% of QC´s CPU. I´d love to utilize that CPU in a meaningful way. The QC could have a “low latency” or “sport” mode which restricts how much processing is available, but also lowers the “buffer size” (or whatever it takes). That way the user could have simpler, more responsive patches and use the “normal latency” mode for huge, complicated ambient patches, etc (where timing isn´t that critical).

Further thoughts:
Ideally this mode should be switchable between scenes (I wouldn´t even mind a subtle click or a short silence, if that´s what it takes), but I´d be happy to have it as a global or per preset parameter as a start.

This idea could go the other way as well: A “high buffer size” or “power mode”, meaning more latency, but also allowing for more processing. Useful for the “mad scientists” (I´ve heard whispers of people maxing out their QC).

It could be implemented as a simple switch - Sport/Normal/(Power) or a slider.
Setting the slider all the way left (“Low buffer size”): Lowest possible latency, pretty restricted processing power.
Setting the slider all the way right (High buffer size): Normal (or maybe higher) latency, maximum processing power.

Hopefully the QC will become more and more efficient, possibly eliminating the need for this function. However, I think it would still be a nice feature in order to cater to the needs of both the “gigging tube amp purists” and the “crazy ambient professors”. Imagine if in the future the QC could do both simple rigs with ultra low latency, or multiple threads of massive ambient rigs with some latency…

Lastly, Nerual: If latency is an issue you are working on, great, please let us know! (But still it´s a neat idea, no…?)

[coimbrafilipe]

I feel the same. Big latency. I see videos of people playing it and it’s possible to hear the latency. I’m very sensible to latency and I think it’s unacceptable the amount that we get on this device. I’m pretty sure it’s above 10ms on most of presets, even without that much of processing. Even with my headphones direct on the quad cortex I feel it. The maximum buffer size I use on computer is 64.

[thomasotto]

Do you have anything in the FX loop(s) ?

I measured (DI straight in vs QC out) that with pedals in FX 1 & 2, latency on a 53% CPU scene was 16ms.
It felt wrong when I was playing through a real cab (itself being a meter or so away so adding latency too)

I had to capture these pedals to stop using the FX Loops.
Now it feels ok to play.

With the latency of a Digital to Analog conversion on a Send and then Analog to Digital on a Return (x2 if using the 2 Loops), I guess the FX Loops are a no go when every millisecond counts… Especially if playing through a cab.

[MortenRL]

@thomasotto

Not, sure if this was intended for me or coimrbafilipe, but no, I don´t currently use the fx loop. I was planning to do so, eventually though, so it´s a bummer if that ads even more latency…

[MortenRL]

@coimbrafilipe

Yes, I definately feel it too, straight from the unit. It baffles me that this is not the nr. 1 feeback of the user base… I haven´t measured how much overall latency I´m getting yet (only measured how much it´s changing from preset to preset). Hopefully I´ll find time to do it in the next few days.

[Andyjcp]

I may not be very sensitive to latency, I sometimes play a few meters away from my amp.

Nevertheless, the 10ms you mentioned seem quite high.
In this video here, the QC is measured with 3.x ms, which should be quite tolerable.
https://youtu.be/oU0-_3Hub9o

PS If my math is correct, 3ms latency should have roughly the same effect as standing at a 1m distance of the speaker. 10ms would be equivalent to 3.4 m distance.
(At room temperature… In a hot club, sound would travel a bit faster )

[HonestOpinion]

@Andyjcp

n this video here, the QC is measured with 3.x ms, which should be quite tolerable.
https://youtu.be/oU0-_3Hub9o

One thing I noticed in Leo’s video (btw, that guy makes great thorough videos) is that he mentions that each of his latency comparisons is done with just an amp and cab or IR in the signal chain. I wonder if it is possible that some modelers are adding significantly more latency as the complexity of the signal chain increases with, for example, more effects or splits, etc… I would love to see a similar latency test video where more complex signal chains are used that might more closely resemble many users’ presets.

[HonestOpinion]

It occurs to me also that some blocks may be better optimized than others. Particularly on a fairly young code base. It is possible that some amps or effects blocks are adding more latency than others.

[Andyjcp]

I had assumed that having more blocks (or more complex blocks) in the preset would only increase the CPU load, but not the latency, like in a DAW with a fixed buffer size.
But actually, my assumption may be totally wrong…
Would be interesting if someone could provide measurements.

[HonestOpinion]

@Andyjcp

I had assumed that having more blocks (or more complex blocks) in the preset would only increase the CPU load, but not the latency, like in a DAW with a fixed buffer size.

Hmm, now that never occurred to me but maybe you’re right.

It does seem inevitable to me that each time you add an additional manipulation to the sound (another block), you add some measure of latency. If it is in nanoseconds though, it would have no significant impact.

Some blocks seem like they could potentially add an even greater degree of latency than usual. Perhaps for example dynamic blocks like compressor, polyphonic effects, or crossover splits which have to calculate the input signal and adapt to it while processing and outputting to the next block. Have no idea of how much time overhead any of this incurs though, or if it is in the least bit significant enough to cause audible latency.

Strictly academic btw, no specific reference here to the QC.

[danimaetrix]

This is in fact the case - it DOES have latency that is measurably quite higher than fractal and boss. I did some measurements of my own with ReaInsert last night (corrected for interface/line loss) and I found the following:

Latency for an empty preset on the QC: ~2ms
Latency for an empty preset on Axe III ~ 2-3 ms

QC with some of my heaviest presets using all 4 lanes - up to 10ms
Fractal with a similarly busy preset - still 4-5 ms

Ad hoc and non scientific, but the latency of the QC definitely scales strongly with the FX and number of lanes used whereas fractal processing may have higher latency sometimes but will often be measurably lower and more consistent. It’s pretty easy to confirm this if you have both devices

This also maybe explains why some people claim the QC has a high latency while others say it’s very low

[HonestOpinion]

If your results are correct, Neural will need to work on further optimizing their code. No surprise there. Add a preset’s 10ms to the 1ms per foot latency for the distance from your monitor, or the latency to your DAW, and that begins to ‘soften’ the feel for some players, if not tragically, noticeably. Not sure what priority optimization and latency reduction will have with all the other tasks on their plate. Hopefully optimization will be dual tracked with whatever else they are working on. It would be interesting to know what the latency numbers were on Fractal, Kemper, and Helix within their first two years.

[danimaetrix]

Yeah - and again, my results aren’t particularly rigorous or scientific. Primarily for my own discovery and I’ve never really noticed latency while playing. But results do seem similar to other claims.

[HonestOpinion]

@danimaetrix

Latency for an empty preset on the QC: ~2ms

Btw, worth noting that the latency for an empty preset is a nice low number, from which I infer that the latency being introduced with a loaded preset is NOT due to a hardware limitation, but more likely a code optimization issue. Especially given the QC’s generous allotment of hardware firepower. That is excellent news as it means latency can be reduced with future updates.

[MortenRL]

Great to see some input on this issue! The QC definately definitely adds more latency when you add more blocks (I’ve tested this).

The point of a device such as the QC is being able to use many modules. If I can only run an amp and a cab, I might as well revert to the Iridium….

My current preset uses less than 50% of the cpu. In my mind, it should be possible to utilize this power the reduce the latency. The power is after all one of the main selling points of the QC… Would love to hear Neurals take on this.

[danimaetrix]

not all modules and amps and cabs are equal. My tests were for a specific case only, and I wouldn’t generalize beyond that. But suffice to say, the MAX latency I observed with heavy presets was 10ms. Most were not that high.

As to CPU usage, you can use it more fully by splittting into rows 3/4. 1/2 and 3/4 are each 50% of the total.

I did not try it with FX loops. That could be more due to extra ADA

[Andyjcp]

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.

[legzalez]

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.

[danimaetrix]

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.

[MortenRL]

@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.