Latency jump when using Row 3 & 4

CorOS Version: 2.0.1

Describe your issue:
When I use Row 3 in conjunction with a Block (any Block or Splitter), I get an added 2.67ms of latency.

It is roughly the equivalent of 2 amp blocks + 3 cab blocks. (around 1ms per amp and cab combo, the amp block being a third of a millisecond).

Described here on the QC numbers report (latency, send levels, etc.) post

Steps to reproduce your issue:

  • Open a blank preset
  • measure your In to Out latency (should be around 1.75ms)
  • insert a Gain Block on Row 1
  • measure your In to Out latency (should be around 1.75ms)
  • Set your Row 1 output to Row 3
  • Drag the Gain Block to Row 3
  • measure your In to Out latency (should be around 4.42ms)

I expected this to happen:
I assumed Rows 3 & 4 did not add any latency to the global grid (preset), but it does.

I have tried the following things:
There seems to be no workaround other than not using Rows 3 & 4 or accepting the added latency.

5 Likes

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

@Max ,

This looks like a solid chunk of deduction !

Maybe you could add/include this post in QC numbers report (latency, send levels, etc.) for reference.

It could enlighten people that have questions on the subject…
That was the aim of the “qc numbers topic” : finding explanations and putting words on what most of us are “feeling” while playing.

Thanks !

1 Like

I am late to this discussion, but it is interesting. I can see that a number of scenarios have been measured, but I am wondering about a specific configuration. As a bass player, I have been using inputs on row 1 and row 3. Row 1 is my basic amp configuration and in some cases can have a number of effects, and in some presets may be simple. Some presets include splitters to row 2 that rejoin back to row 1. The row 3 input is basically a DI and may have a compressor and EQ. I have noted in the past that it seems like sometimes there can be phasing issues between the two outputs. Given your experience so far, is there an obvious way to avoid or correct this?

1 Like

I haven’t looked into that. Perhaps you could try recording both outputs simultaneously and lining them up in the DAW to verify that there’s indeed phase mismatch between them? Perhaps, you’ve already done this, LMK. It’s just that it’s possible that phasing is caused by something else, e.g. the audio playback equipment connected to those outputs, the relative distance to your ears, etc.

My best guess on this topic (also not a DSP expert) is that DSP #1 is hard-wired to all the I/O ports (AD/DA, USB etc.), so DSP #2 needs to communicate with DSP #1. To underline this theory, it’s quite clear that DSP #1 (or whichever is responsible for Rows 1+2) also needs to process the global EQ which is the reason why it chokes easier on higher DSP load (“EQ crossed out flashing”).
Most probably, like with an audio interface on a computer, the I/O latency between the two DSPs is 64 samples on input and 64 samples on output to prevent buffer underrun (total 128 samples).
That may not be what I think of when I read “quad core system”, so I better stick exclusively to Rows 1+2 when I want the quickest route from the in to the out. :expressionless:

All, remember that if you are experiencing latency within your setup and unable to resolve, please email support@neuraldsp.com to log the issue and hopefully resolve. Thanks!