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

[PeterO]

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.

[DavideAru]

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

[thomasotto]

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)

[thomasotto]

It’s a feature request now :

Preset Latency Monitor rather than a CPU Monitor (or both if possible)

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]

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.

[thomasotto]

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 :

[sleiweke]

@thomasotto thanks for doing this chart. keep em coming!

[PeterO]

@DavideAru

a pedal board with this power cannot have these problems

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.

[thomasotto]

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.

[DavideAru]

@thomasotto Thanks for the valuable work!

[DavideAru]

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

[Niksounds]

@PeterO

strain

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

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

[Max]

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

[Max]

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.

[Wolfgang]

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.

[thomasotto]

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…

[Wolfgang]

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?

[thomasotto]

@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) !

[DavideAru]

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!

[onyir]

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