BUG: plugin delay compensation is broken

What crucial is, is that the project is closed before switching SR and re-opened after the SR was changed.

I can only change the sample rate of the session when the session is open, so I can’t really do what you are requesting.

Besides, Nuendo allows the user to change buffer sizes and change sample rates at any time. Nuendo should not allow these actions to disrupt sample accuracy and it should not be on the user to follow an specific but unstated workflow in order to maintain sample accuracy.

Given that both UAD Dreamverb and Altiverb have exhibited this issue it seems Nuendo related.

Given that the issue does not FIX itself on session reload or system restart it seems Nuendo is not re-calculation of the latency properly.

Also, be sure you have two identical tracks.

All my tracks are identical, same audio file. No other plugins are active, or loaded during this test. Just the plugin under test.

Thanks for looking into this Fredo, it been a thorn in my side for while now. Hopefully we can get to the bottom of this. This is a high importance issue for me as my mixing workflow often involves mixing processed and unprocessed versions of the same source.

I also have an RME but I still can not repro your issue. I would try a different system or audio card if you can and see if the problem is still there.

I’ve been tag teaming this issue with others, there is no question it exists. If you really want to reproduce it you’ll have to try every combination of sample rate & buffer setting. I’ll write the steps again from my initial post…

-create 44.1 sample rate session @ 512 buffer size
-make two identical tracks (with same source audio)
-flip phase of one track using mixer phase button
-put a plugin (altiverb or UAD Dreamverb plugin) on one of the tracks
-set said plugin to DRY (so it just passes unprocessed audio but still goes thru the plugin buffer)
-master fader meter should show no signal
-repeat for every sample rate
-repeat for every buffer size

Even if you restart the system or nuendo between each test you will eventually run into this issue.

Did you see my screen shots? How can they be wrong? The master fader shows signal or it doesn’t. If there are two sessions, one which shows signal in the master fader and one that doesn’t and the only difference is the buffer size, there is definitely something wrong with Nuendo’s handling of the PDC numbers.

The only other variable is the type of plugin, some plugins don’t have the issue, others do. In my example, the steinberg VST3 mono delay did not experience the issue when the UAD plugin did. Altiverb did also. I also tested Line 6 plugins, URS plugins, SPL, Brainworks… but alas not at every SR / buffer setting, just in the same session. I loaded a bunch of plugins on a channel and saved and reloaded the session and the issue only showed up in Altiverb in one case. The other plugins continued to pass the null test.

I think the only valuable input anyone can contribute is to find a repro case on their system. But you will have to be diligent. You will have to spend the time and try every combination until you repro.

Everything else is just conjecture otherwise.

I will refer you to my first post on the issue. Some plug-ins say “dry” when they are in fact not. The plug-in could absolutely have a bug where it behaves incorrectly at certain sample rates and/or buffer sizes but that should be reported to the developer of the plug-in.

Have you tried a different DAW? A different computer? A different soundcard? It could be any number of things and while the end result might appear that Nuendo is broken, the problem might actually lie elsewhere. I’ll mention it again, using your repro steps I was unable to reproduce the bug and I use parallel processing all the time.

using your repro steps I was unable to reproduce the bug

Did you test every buffer size and sample rate? Unless you tested EVERYTHING you didn’t perform my repro steps. Again, the issue may be intermittent.

Some plug-ins say “dry” when they are in fact not

I was able to repro this issue with UAD Lexicon, Cambridge, Dreamverb, and Altiverb. They all exhibit the same behavior and I know the Lexicon passes dry.

You see the null test is mathematical. If each sample in the two tracks is identical and you sum then out of phase you get silence. I could bounce these tracks down and bit for bit compare the audio content of the files for further proof, but if I see a meter that goes down -46 dbfs and I here nothing there is a REALLY good chance the two tracks are the same.

Have you tried a different DAW

I also performed this test in Protools and Logic with the same plugin and guess what? The issue didn’t occur!

A different computer? A different soundcard?

There is no need to try a different sound card or computer because this issue is occurring beween the timing of the tracks, before the audio even hits the soundcard D/A.

I think at this point it may be more beneficial to provide fact or test results in lue of speculation. If you do get a chance to perform the entire repro steps with all buffer size and all sample rate combo’s it would be very useful to know your results.

I have tried all your sample rates and buffer sizes (well, what I could as my RME card has different options available) and still no problem. Just for fun I tried with the Lexicon Hall (latest native release from Lexicon’s site) and still no issue.

I suggest re-reading what I wrote. Plug-ins can behave differently at different buffer sizes/sample rates (and your audio hardware can certainly affect things) so if the problem is not happening with the built-in Steinberg ones (which you indicated that they were not and I certainly can’t reproduce your issue with them) then that to me points towards your other plug-ins being the source of the issue.

I have had had 3rd party plug-ins show different results depending on host buffer size and sample rate which were fixed by the plug-in manufacturers.

That’s all I have to say on the subject. Good luck!

The issue still happens if the plugin is bypassed.

What is surprising is that all the “faulty” plugins seem to be reverbs …

Fredo

Alright, so you have a repro Fredo?

Come on, give me a break man …
I responded last night at 21.23, and then again this morning at 7.30.
Sometimes I do sleep you know …
I have just arrived in the studio, I’ll see where I can squeeze it in today.

Fredo

Sorry :wink:

Tested Altiverb, Speakerphone, Dreamreverb, Realverb pro, EMt140 and Roomworks.
They all null perfectly, even after switching SR with the project open.


Fredo

At which buffer size?

A few different, I randomly changed the buffer when testing each plugin.

In my line of thinking, that is also something strange, 'cause the buffer size is set at the soundcard, which is after and independent of the DAW’s playback of individual channels.
I also must say that we are working in a very “tight” environment. All our studios are clocked by a Master Video clock, and each component in the studio (soundcard, converters, etc …) is again clocked by a Studio Master Word Clock.
So when we change SR, it is done on our Rosendahls, and the DAW just follows.
Maybe your case is different sicne it is your DAW that is “controlling” the soundcard.
I would check all your settings, especially those that link the DAW with the soundcard. Like the “adjust for record latency”, and see if any inputs (of the concerned tracks) are connected to teh soundcard.

I tested Playback in a locked environment. That rules out most -if not all- problems of the link between soundcard and DAW. In conclusion, it seems that the plugins report their latency correctly, and that the DAW correctly compensates for.

Fredo

I’ve tested this with several plugins on a track. Some plugins pass the audio unaffected. Others on the same track pass it offset. So it’s not an issue with the track, just the individual plugin.

I will post a video of me recreating the issue from scratch.

Although it is not a UA-specific bug, Universal Audio’s QA team has been able to repro this issue in-house as well.

Here is a screen capture of the bug.

I’ve created a new session using built in internal audio of my MacPro. The sample rate is 48k and the hardware buffer size is 1024.

-I create two identical tracks
-put one out of phase so they cancel out completely
-add a cambridge EQ to one track
-bypassed the cambridge EQ so 100% dry signal is output
-playback shows both tracks cancel out (plugin delay is accurately compensated for)
-change hardware buffer size to 768
-BUG: playback shows both tracks NO LONGER cancel out (plugin delay is incorrect)
-powering off cambridge, tracks cancel out again

System detail:
MacPro 1,1
9GB memory
Nuendo 5.1.1
UAD 5.9.1
OSX 10.6.7 (freshly installed from scratch on new partition)

Fredo,
Please let me know if there is any missing detail. I want to be sure this issue is escalated to Steinberg QA with all data needed. Feel free to request more data.

Thanks much, look forward to finding the root of this problem!

Cheers.

There are a couple of things missing from your repro:

  1. What happens it you save the session, close the project, change the buffer and then re-open the project?
  2. What happens it you save the session, close Nuendo, change the buffer and then re-open the project?

I don’t have N5, but in N4 there is no way that I would ever change the buffer whilst a project is open. It would always cause glitches and problems if I tried it.

DG

Please read the entire thread before posting.

Ive already stated that this issue persists even if you close the session, nuendo, or reboot the system.

It is perfectly plausible to change the buffer size mid session. When you increase your project resources to where the engine begins dropping audio buffers (clicks and pops) you need to bump up the buffer size. There is nothing wrong with doing this.

You cannot change the hardware buffer size outside nuendo. Not for RME, nor for internal built in audio as far as I know.

You may have stated it, but you didn’t prove it with your repro. No need to be snarky when I was only trying help.

BTW there are many soundcards that allow you to change the hardware buffer outside of Nuendo. RME is one of them.

DG