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

Quad Cortex
25

The latency is not really related to (processing) power. It’s simply not possible to avoid buffering of samples, and the latency it result in, when audio samples is passed to a processor. In a system with more CPU cores processing power can be increased if it’s possible to process audio in parallel but that’s not the typical way we use our QC. Instead everything is processed in series and if a preset needs to use a second core added latency will be a result of that.

Latency caused by buffering can be reduced by raising the sample rate and/or reducing the buffer size. Both will put more strain on the CPU. I’m not seeing a massive surplus of processing power with the current sample rate and buffer size, so I think Neural DSP has reached a reasonably compromise between processing power and sample rate / buffer size.

I’m not saying that latency in the QC can’t be any lower than it is, but I will be surprised if it’s possible to lower it significantly.

3 Likes
26

Here is another test made with an additional audio interface.
It confirms the Row 3 latency measure via USB. (I feel more confident with the numbers I posted via USB)
The only slight difference is the QC base latency being a tenth of a millisecond superior.

Screenshot 2023-03-13 at 11.44.49
Screenshot 2023-03-13 at 11.44.492134×408 116 KB

2 Likes
27

@thomasotto Thanks for the valuable work!

28

@PeterO Thank you ! I don’t know what it could depend on but one thing is certain Neural has to solve it! I am sure it will! at least I hope so otherwise I’ll have to put my QC back in the box!

1 Like
29

Not only serial…

I tell a story

Pierino uses only row 1 with 4 blocks and the dsp1 computes each block with 1 ms (casual value). Pierino has 4ms of latency

Then you Say…if i route row 1 in 3…and i add another 4 block…dsp2 has to attempt the dsp1 processing… At the end Pierino has 8 ms of latency :smiley:

I Say…NO!

Why, meantime dsp1 elaborates, dsp2 Is with Orpheus?

The fine idea Is THAT , when you have for example row 1and 3 routed, Twice dsp are in work at the same time…and every block Is processed in 0,5ms… Result? Circa 4 ms… With 8 blocks. Simplified

1 Like
30

@thomasotto asked me to copy my response to his bug report on this thread. Here it is, though it looks like @PeterO already expressed a similar idea:

"I don’t work for Neural DSP, but I think I can make an educated guess on why we are observing this behavior.

It has been confirmed that Rows 3 & 4 are handled by a different DSP core. Based on your measurements, that second DSP is processing the output of the first DSP in buffers of 128 samples. Given the sample rate of 48 kHz, we’re getting:

128/48000 = 0.00266(6), which precisely matches the additional 2.67 ms of latency you’re measuring.

Some additional latency is inevitable whenever buffering is involved, but it is a mystery to me why that buffer has to be that large considering that Rows 1 & 2 clearly work with a smaller buffer (otherwise it wouldn’t be possible to get the 1.75 ms number you’re quoting, and what the other people have measured on simple presets utilizing only Rows 1 & 2)."

2 Likes
31

By the way, since you’ve started collecting data on block induced latency… I haven’t done any measurements recently, but I’ve experimented quite a bit with firmware 1.4.1 using RTL Utility from Oblique Audio.

One interesting finding was that the incremental latency of a particular block can vary depending on the preset, i.e. a block that is latency free in some scenarios could be increasing latency in others, depending on what other blocks were on the grid. I’ve seen this behavior for all kinds of blocks, including noise gates, NuVibes, etc.

I’ve done all these tests utilizing only Row 1 so that I don’t mistake the impact of the block with usage of 2 DSP chips. One hypothesis I have for this behavior is that QC may be automatically adjusting the buffer size when it hits certain thresholds. It’s also possible that even on a single row it automatically splits the executing between two cores of the same DSP chip when necessary (I believe QC has 2 DSP chips, each having 2 cores), and a small buffer is required to synchronize them.

The most bizarre thing was that I created a preset that had different latencies depending on the order in which it was built. Maybe I can find it and see if I can reproduce that on firmware 2.0.1.

2 Likes
32

Just came across this thread via NDSP’s mail out.

To be clear, is the latency discussion realted to latency occuribg when using the until as a sound interface? Or is is this also occorung when say your NDSP is connected to an FRFR speakers?

I must say, reading this has started me question a litttle my deciciin to move to a QC from a Fractal.

1 Like
33

Hi @Wolfgang,

If you read the very first post, you should see that the tests do NOT include the “interfacing” latency.
If that wasn’t the case, there would be much more than 1.75ms latency for a blank preset.
The numbers you see are measured from In to Out directly.

Please take the time to visit the Preset Latency Monitor rather than a CPU Monitor (or both if possible) feature request should you consider voting for it.
It could make our lives easier…

1 Like
34

Hi Thomas, many thanks for confirming. This is dissapounting to hear, but at the same time id be intrested to know if the latency has ever caused people issues is say either a live scerario or seperately in a recording scenario?
The lag reads like it’s a lot but perhaps in practive is doesnt feel noticable when playing?

35

:raised_hand: @Wolfgang

I don’t think there’s a latency number that fits all people.
Some people’s brain will accept 10ms without a problem.

Here I can only speak for myself :
I bought the QC with the intention of having a “all types of situation” preset.

This preset had 4 mod Blocks, 2 drive Captures, 1 fuzz Block, 1 compressor, 1 “girth” drive Block for simulating an amp breakup, 1 eq for one annoying guitar frequency, 1 slap-back delay, 1 tap-tempo long delay, 1 room reverb, 1 shimmer reverb, 1 amp combo Capture, 1 eq for high-end/low-end tailoring.

Everything on 4 rows with 1 output for my stage amp & 1 for FOH.
This added up to 9.75ms

The latency + being a couple of meters from my amp made it really hard to play for me (fighting against the fact I was always a bit behind the drummer).

Then again, I have been working my chops all my life with a click, my own backing tracks/loops or some kind of Band In A Box equivalent.
I like to be able to play tightly on the Grid, play laid-back, play aggressive (ahead of time), and doing all of that intentionally of course if I need to.

So I’ve been compromising ever since :

  • No Rows 3&4 (+2.67ms)
  • Avoid FXLoops (except if really needed) (+1.85ms per Loop)
  • Use the Send 1 Output to my stage amp (so that I can put the block anywhere on the grid and not have to use a row Output)
  • Multiply presets if I need multiple/different mod Blocks that wouldn’t fit on Rows 1&2.

I’m still keeping all my analog Amps, Cabs, Pedals.
Not too sure at this time if I wouldn’t switch back if NDSP took ages to optimise/fix those latency issues.

And, as a reminder, this is totally subjective (just my point of view) !

:wink:

4 Likes
36

I think @thomasotto absolutely right the machine has an unacceptable latency especially given its power much advertised by neural! the problem is in my opinion too big for the neural to do nothing! Another thing that makes me think is how is it possible that they didn’t notice the volume problems of its effects loops during the test phase? How is it possible ? I can accept a software bug that maybe needs to be found but not a bug so simple to find with a simple test by putting a pedal in send and return! among other things, the loops only there specially! how did they test them?! @Wolfgang @Max Sorry for tagging you like this but I just read about your discussion! :wink:

2 Likes
37

Hi. I haven’t been able to replicate your results for the fx loop levels. I do find that the QC reports higher levels in the I/O screen, but when measured with a separated sound card, I get basically unity gain

1 Like
38

@thomasotto I hope they fixed this latency issue with this firmware which is more important to me than adding more amps! :crossed_fingers:t4:

2 Likes
39

I don’t think.
They need more time shurely for this point, programming side.

40

@Niksoundsthis latency stuff that doesn’t get resolved is absurd!

2 Likes
41

Hi @thomasotto
Does this mean that I can reamp DI tracks with a real amp, without a dedicated reamp box, by using the FX send and decreasing the output by 4.5db? Would there be any other issues like impedance?

42

Yep !
Fingers crossed !

1 Like
43

Hey
It could probably work.
I’d save a recorded track for reference though.
Just to do comparisons between reamped and original sounds.
Worth a try

44

Hi!
Just wanted to chime in on that one as I never paid much attention to latency issues playing via my Axe-FX III. Now that I sold the Fractal unit and moved on to the QC, all that latency talk got me kinda paranoid.
Today I contacted the guy who bought my Axe and asked him if I could do some tests with my former unit.
And the results were kinda… not in favour of the Fractal unit at all. I was actually quite surprised that some of my former live presets that are still on the unit are beyond 10 ms.

So rest assure, as long as you can’t evade having a series of modules to process your signal, you will face latency in regards to the number of turns that the DSP requires for the complex calculations.

4 Likes