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

[thomasotto]

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)

[thomasotto]

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 !

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