BUG: plugin delay compensation is broken

Nuendo 5.1.1
mac OSX 10.6.7
RME 2.91

I’ve found that plugin delay compensation is not working at multiple buffer sizes / sample rates. Plugin delay is incorrect, is not sample accurate, thus null tests fail, parallel mixing results in comb filtering.

-make two identical tracks (with same source audio)
-flip phase of one track using mixer phase button
-put a plugin on one of the tracks
-set said plugin to DRY (so it just passes unprocessed audio but still goes thru the plugin buffer)
-listen… tracks should cancel out to silence

-try at different hardware buffer settings
-try at different sample rate settings

Of all buffer and sample rate variations I was able to find 7 combinations that failed this null test.

Can anyone reproduce?

Difficult test to do. Which plug-ins? Some plug-ins that say dry are not in fact passing the signal straight through unaffected.

Try a steinberg plugin with wet/dry.

Can’t reproduce.

  • Create 2 mono audio tracks feeding to two mono groups (just to be sure we’re getting the end of the signal chain post inserts on the audio tracks)
  • Put an audio file on each track (sine tone is easy)
  • Flip the phase on group channel 2
    —> Silence at the output
  • Insert a plug-on on audio track 2 (let’s try the mono delay or reverb) and set the mix ratio to 100% dry
    —> Silence at the output

You have try several sample rates and bit depths. I tried EVERY combination and found 7 cases where this test failed.

The following FAILED…

Buffer | Sample Rate

128 @ 96
192 @ 192
512 @ 48, 192
768 @ 48
1024 @ 96
2048 @ 192

I have noticed this a while ago… I guess I should have posted about it. :confused:

YES! Nuendo has always touted sample accuracy… unfortunately something went wrong and its been broken for a while. I know others that can also repro this.

This is a major issue for me as I ofter paralel mix. I would love an ETA on the fix? :stuck_out_tongue:

Can anyone at Steinberg repro / comment?

Thanks much

I tried your test with the following:

128 @ 96
512 @ 48
1024 @ 96

Still can’t reproduce here.

Try them all.

Is there a reason why you don’t tell us which plugins, at which SR causes problems?


My audio card won’t do all of those buffer settings and/or sample rates - my time in the day won’t allow it either :wink:

I tried the ones I could (you’re welcome) and your repro didn’t work.

Either provide more detailed instructions as to an EXACT repro (plug-in, audio hardware, OS configuration etc) or try a different audio card on your system (or another system altogether).

…from above…

The following FAILED…

Buffer | Sample Rate

128 @ 96
192 @ 192
512 @ 48, 192
768 @ 48
1024 @ 96
2048 @ 192
Junior Member

This issue may not have an EXACT repro.
I will repro again and let you know which plugin.

Just reproduced the issue…

OSX 10.6.7 (Fresh Install)
Nuendo 5.1.1
RME (2.91) dual Fireface 800 daisy chained, synced over word clock (aggregate device)

-setup session with one steinberg plugin, one UAD plugin
-check null test
-UAD plugin buffer was incorrect
-steinberg plugin buffer was correct
null test.jpg
I checked 1024 buffer size and started with 44, then changed session to 96 (didn’t convert), then 176, 192, then 48. On 48k the issue was reproduced (only for the UAD plugin).

Not sure if this is a UAD bug or Nuendo bug only exhibited with UAD.
UAD only.png

Here is a repro using only altiverb… I can toggle back and forth between 44.1k and 48k @ 768 buffer and see the issue come and go…
altiverb 768 @ 44k.png
altiverb 768 @ 48k.png
So perhaps this is not UAD related…

Question: are you actually shutting down and restarting Nuendo between tests, as opposed to just toggling back and forth in an open session?


I am not shutting down, restarting Nuendo… and I shouldn’t have to.

Also note, this issue does not go away even if I restart my system. It’s like the incorrect buffer is “cached” somewhere.

That really depends on what you’re trying to do. Basic troubleshooting protocol suggests you should.


At least you should re-load your project.
Delay compensation is calcluated when the plugin is loaded; that is either when the project is loaded (with the plugins)or the plugin is loaded into the project. When switching sample rates the delay is not re-calculated and re-applied.


As I stated already, restarting the system doesn’t even fix this issue thus restarting Nuendo does not fix it. Just retested and that is the case.

Restarting the DAW every time I change buffer sizes during a mix is less then desirable IMO.

Fredo, are you able to repro?
What are your thoughts on this issue?
Is it a bug?

What crucial is, is that the project is closed before switching SR and re-opened after the SR was changed.
Any change of SR within an open project will -AFAIK-and I could be wrong- not result in a re-calculation of the latency.

Haven’t got the time to repro yet, will try tomorrow.
It’s hard to tell if it’s a bug. The procedure is that the plugin needs to report the latency to the host, then (and only then) the host applies (if needed) compensation for it. If the problem is confirmed, then it are the engineers who need to figure out if the latency is correctly communicated to the host and/or if the latency is correctly compensated for.

Also, be sure you have two identical tracks. If one track has -for example- an extra plugin with a higher latency, then that track will be compensated for the highest reported latency.

I seem to remember vaguely some delay compensation problems with UAD plugins, but that is a very long time ago.
And knowing UAD QA, it would surprise me very much if the problem would be on their side.