vst(i) latency issue

Cubase
,
1

there is a weired bug where adding fx to audio or vst tracks adds the latency
of the added plugin on a global level.

so midi input becomes sluggish pretty fast.

this was not the case before cubase 8 .
with earlier versions (sx - 7.5) i was able to add fx up to the last cpu cycle and the latency stayed the way
it was selected in my interface.

other users confirmed this bug on gearslutz .

2

win10, cubase 8.5.15 (x64), rme babyface (original version, with the latest/greatest drivers).

I’m having the same issue.
Repro steps:

  1. Add several audio tracks (in my case it doesn’t matter if there’s any audio on them or not, 15 tracks should be plenty).
  2. Add a high-latency plug-in to each track. DMG’s equilibrium is what i’m using (Analog phase mode, with a window size of 8192. Cubase reports its latency as 4096 in the plugin manager).
  3. Add an instrument track with a vsti of your choice (don’t use any insert plugins, just the instrument). Set the track to record-enable, and play midi notes on your controller of choice. The vsti playback will be delayed.
  4. Create an audio track (again, with no effects), and record-enable it. Send audio signal in on that channel. Monitored signal will be delayed similarly to the vsti.
  5. Enable Constrain Delay Compensation, and play midi notes on your controller, or pass audio on the dry record-enabled track. Additional latency on monitored signal is no longer present.

Additional notes:
The more high-latency plugins you add, the greater the monitoring latency. It starts getting noticeable after just a few. What’s the maximum PDC Cubase 8 is capable of? OP mentions that Cubase 7 didn’t exhibit this problem. Reaper does not either.
This issue happens whether or not there’s audio passing through channels (in other words, whether i use a full mix with wav files, or just empty tracks, the issue is the same. I don’t even have to play back for it to be apparent, but the behavior is the same on playback anyway).

Changing buffer settings doesn’t seem to make any difference, nor does disabling ASIO Guard.

The OP and myself both use RME interfaces. Can someone with a non-RME interface confirm?

Thanks,
kell

3

i think its safe to say that this problem
is easily connectable to all this issues

render in place bug

extra audio length on export

export audio progress bar not working

vst(i) latency issue

4

All what you discribe here is normal behaviour and has always behaved like this.
When latency heavy plugins are added, all other tracks are delayed aswell to keep all tracks in sync.
Plugin latency is not the same as audio buffer latency. Plugin latency can not be decreased by reducing buffersize. Its fixed. It also can not be reduce for realtime dependend tracks. Thats why Asio Guard does not work on tracks with monitoring enabled. Because it can not know what happens before it happens.

If you constrain the delay compensation all plugins with noticable latency will be deactivated and you will have low latency monitoring again. This function is exactly intended for this

5

i dont know mate, i def. never had those issues prior to cubase 8.

6

Well i have to take your word for it than :mrgreen:

Your linked topics are actually all unrelated to this topic here.
the render in place bug i can not reproduce neither on C8.5 nor C8. I showed this here

no progress bar on export is exactly how related ? :question:

Adding latency heavy plugins has allways resulted in more overall latency while monitoring the track. Thats the way it allways worked. At least for me.
Think about it. How can the latency not be increased when monitoring. Lets say you have a plugin with a large internal buffer. Like linear phase eq or look ahead limiter/compressors. they need time to process the audio before putting it out. I order to put out the audio with no additional latency means they need to start processing before you even hit the key on your masterkeyboard. But they can not process something that isn’t there yet.
ASIO Guard does exactly that. Precalculating tracks that are not realtime dependend outside the Asio System than feeding it back to the asio stream with no to little additional latency