ASIO Latency Compensation Problems

I believe that I do understand everything you posted and have tried my best to correct your misconceptions. But, no matter how hard I try and for whatever reason, I apparently can’t get you to understand and/or acknowledge what I have written and/or the associated substantiating test results. I was hoping the reason was a language barrier resulting from your use of inadequate language translation software (which could also explain your grammar and spelling errors).

I do understand and have explained (several times now) how it works in Cubase 8.5. You have shown (despite your claim to the contrary) that it works differently in Cubase 9. Can you please explain how you think it works in both versions and what its intended purpose is in each?

Please note that my response was intended to show that your statement about plugin delay compensation contradicted what the manual says – sorry if I didn’t make that clear enough!

Maybe so! I think of DAW record latency compensation as the time shifting of newly recorded tracks to align them with previously recorded tracks. To do so accurately, that time shift needs to include the input and output latencies of the audio interface, an accurate plugin delay compensation (PDC) delay value, and an accurate ASIO Guard delay. I.e. the time shift should be equal to the sum of the DAW system’s overall playback and record delays (call it DAW System Round Trip Delay – SRTD?) To my knowledge Cubase can’t measure SRTD so it relies the accurate reporting of the interface latencies, plugin delays, and an accurate application/reporting of PDC as well as ASIO Guard delay. The purpose of PDC is to add appropriate delays to each track to time align them with the track with the largest delay during playback. Is this correct?

It, like the analogous “FX Anticipative Processing” in Reaper adds playback delay that needs to be included for proper record latency compensation (call it SRTD compensation?) as defined above.

Sorry! Since my

was apparently inadequate, I’ll elaborate. Cubase 8.5 always adds latency to VSTi that may not always be appropriate, necessary, and/or desirable. The magnitude of this delay is determined by the reported input latency of the audio interface, which can be rather significant.

I really hope that the Steinberg folks don’t share your point of view. I spent a lot of time trying to inform them of deficiencies that would be in everyone’s best interest to correct. Hopefully it wasn’t a total waste :frowning:

I freely admit that I’m not an expert on this stuff and am still struggling to fully understand it. Since the published and/or posted information on this matter is quite limited and often misleading and/or incorrect, I’ve been doing my own testing to fill in some of the blanks. Surely someone out there really understands these subjects (or at least has a better understanding than me). Please help me and others do so too! If you think that my reasoning/conclusions are flawed, please post accordingly (and provide a meaningful/detailed explanation) - I’m not sensitive! It you agree with me, please post accordingly too – hopefully that would help incentivize Steinberg to fix things! If you have questions about what I’ve posted, please ask!

Thanks :slight_smile:

well this is rich. You think i have a misconception of things but you admit to not beeing an expert on this. You still think you you are right about it and that i am the one failing to understand the “Problem” As hard as you tried to convince me that cubase has a problem i tried the same to explain to you that your test environment is flawed…without success
Welcome to the club than.

You still fail to understand that your test setup doesn’t make any sense as it does routing that is not intended or helpful in a real project.

But that you still are not able to explain to me what you really want to do with cubase i have to assume that you have absolutely no clue how Cubase works or how to work with it. Otherwise i don’t understand what is so difficult to answer me that question

Maybe someone else might get through to you and makes you understand that your problem is irrelevant when cubase is used the way it is intended to be used. but i am out here.

good luck than

I now see that only the plugin delays on input tracks are impacted. That makes a lot more sense! Sorry! :blush:

In conclusion(?)

Page 239 of the CUBASE PRO 8.5 Operation Manual says:
If you perform a live recording on a VST instrument, you usually compensate the
latency of the audio card by playing earlier. In consequence, the timestamps are
recorded too early. If you activate the ASIO Latency Compensation button on the
track list, all recorded events are moved by the current latency setting.”

Cubase 8.5 and 9.0.10 really do the following: They delay MIDI note inputs from keyboards/controllers by the reported input latency of the audio interface [for both recording and internal virtual instrument (VSTi) triggering]. The monitored audio outputs of those VSTis are further delayed by the output latency of the audio interface. So, assuming the performer is monitoring with headphones, the perceived delay between pressing the key/pad is equal to the sum of the audio interface’s reported input latency and its actual output latency. The state of the ASIO Latency Compensation (ALC) control does not affect this.

When ALC is active on an instrument track (it has no effect on other MIDI tracks), Cubase will delay the recording of the MIDI note on that track by the reported output latency of the audio interface. The performer will be trying to “compensate” for his/her perceived latency (the sum of the audio interface’s reported input latency and its actual output latency). If he/she manages to do that, audio from subsequent playback of that VSTi will precede the audio from other playback tracks by the input latency of the audio interface (assuming the interface reported input and output latencies are correct). For ALC to do what the manual says it should, MIDI note recording on VSTi tracks should be delayed by an additional amount equal to the reported input latency of the audio interface.

IMHO changing ALC to perform as follows would be far more useful than just fixing it to reflect what is alluded to in the manual. When ALC is active, MIDI inputs should be delayed by the reported input latency of the audio interface. This would help keep them synchronized with the monitoring and recording of other inputs. This would help keep the monitoring and recording of external instruments triggered by those outputs synchronized with other inputs. Everything would remain synchronized on subsequent playback as well.

Cubase now always adds monitoring latency to MIDI inputs from keyboards/controllers to help keep everything synchronized for recording and monitoring. Performers wishing to minimize their monitoring latency from the instruments which those inputs trigger might like to have the option of preventing Cubase from adding that latency. De-activating ALC on selected MIDI/VSTi tracks could (should?) do that! Less monitoring latency would make it easier for performers that wish to “compensate” for it themselves to do so (as suggested by Novikthewise as well as the Reason and Ableton operator manuals). With VSTi’s they would still be “compensating” for the MIDI input latency and the output latency of the audio interface, so Cubase should still delay MIDI recording on those tracks by the interface’s reported output latency.

It should be noted that the efficacy of all of Cubase’s latency compensation schemes/activities rely on the accurate reporting of both input and output latencies by the audio interface. Some, like the 1st generation Focusrite Scarlett 6i6, report the sum of input and output latencies correctly, but not the individual latencies. Since, unlike Reaper, Cubase does not allow the setting of separate input and output latencies for those that don’t, this causes MIDI timing problems. :slight_smile:

Here’s a more concise description of what I did in this thread and why I did it. Hopefully it will help those who wishing to achieve a better understand of these issues do so.

The test setup can provide relative timing information with sample period accuracy. It was used in this thread to help me (and hopefully some others) understand what MIDI ASIO Latency Compensation really does in Cubase. It can also be used to measure/compare the delay of tracks. With a slight modification (playing back tracks while recording the associated loopbacks), it can be used to determine the accuracy of the compensation that Cubase applies to adjust record timings to accommodate those delays. ( shows that procedure. (Note that this forum rather annoyingly opens URLs onto the source’s web page – so it’s best to right click on the link and open it in a new browser tab or window.)

The following assumes that Novikthewise, other than using a different version of Cubase (9 vs. 8.5), a different VSTi, and a different audio interface, followed the same procedures that I did for testing/demonstration.
My results with ALC OFF are here:
My results with ALC ON are here:
Novikthewise’s with ALC OFF and on are here:

Tracks 1 & 7 are recordings of waveforms produced by microphones tapping keys on MIDI keyboard/controllers. Those waveforms were monitored while they were being recorded onto the tracks. The input latency of the audio interface delayed Cubase’s acquisition (and hence recording) of the waveforms. The monitoring of the waveforms (via the track 1 & 7 interface outputs) was further delayed by the output latency of the audio interface. So, assuming headphones were used, the monitored sounds of the tapping (on tracks 1 & 7) would be delayed by the sum of the audio interface’s input and output latencies (its Round-Trip Latency or RTL) from the tapping. They would also be delayed by the interface’s output latency from their recordings.

The Track 1 & 7 interface outputs were externally connected to interface inputs for recording on tracks 2 & 8. The interface’s input latency delayed Cubase’s acquisition (and hence recording) of those monitored waveforms.

The interface’s output latency delayed the monitored outputs with respect to their recordings (on tracks 1 & 7). The external output to input connections at the interface added no latency. The input latency of the interface delayed the recording of the monitored waveforms. So, the delay from the microphone recordings (tracks 1 & 7) to their monitored (looped back) recordings (tracks 2 & 8) is the interface’s RTL (just like the latency of the monitored tapping sounds).

As stated previously, Cubase’s acquisition of MIDI notes caused by the microphone taps on the MIDI keyboard/controller keys were delayed by the keyboard/controller latencies. Since these delays are typically about several milliseconds (ms), they’re much shorter than the audio interface’s input latency in these tests. If Cubase didn’t delay the recording of these notes, their recordings (tracks 3 and 9) would precede the microphone recordings (tracks 1 & 7) by the difference in those two latencies. Cubase doesn’t know the MIDI latency so it can’t automatically adjust MIDI note recordings for that. But, since the audio interface reports its input latency, it can adjust for that (to the accuracy of the report). The delay between the microphone recordings (tracks 1 & 7) and the MIDI note recordings (tracks 3 & 9 respectively) was several ms (the MIDI latency) - showing that Cubase did indeed delay the MIDI input by the reported input latency of the interface. A simple way to demonstrate/prove this is to use a microphone to tap a key on a keyboard/controller and record the resulting microphone (track 1) and MIDI (track 2) outputs at two different interface buffer sizes. The differences in the delays shown in the recordings of tracks 1 & 2 will be equal to the difference in the reported interface input latencies shown for the two buffer sizes (shown by Cubase in the VST Audio Device setup window).

In addition to recording the MIDI notes on tracks 3 & 9, Cubase used the notes to trigger internal virtual instruments (VSTis) on tracks 5 & 11. The monitored VSTi audio outputs (tracks 5 & 11) were externally connected to interface inputs for recording on tracks 6 & 12. The monitored VSTi audio outputs (tracks 5 & 11) were delayed by the output latency of the audio interface. Their looped back recordings (tracks 6 & 12) were further delayed by the input latency of the audio interface.

My test results show that the looped back microphone recordings (track 2) and the looped back VSTi recordings (track6) were only offset several ms from each other. Both tracks were delayed by the audio interface’s RTL. With respect to the tap events, the audio interface’s input latency further delayed the recorded loop back microphone waveforms (track 2). So, Cubase apparently delayed the VSTi triggering by the reported input latency of the interface (as it did with the MIDI note recording).

The only notable difference in my two test results is that when MIDI ASIO Latency Compensation (ALC) was active, the recording of the MIDI note on the VSTi track experienced an additional delay equal to the reported output latency of the audio interface.

Novikthewise showed significantly different results with respect to the looped back VSTi audio recording on both tracks 6 (ALC “inactive”) and track 12 (ALC “active”). In his “inactive” case the looped back VSTi recording preceded the looped back microphone recording by approximately 18.4 ms. In the “active” case the VSTi loopback preceded the microphone loopback by approximately 48.4 ms (half the interface’s RTL). Yesterday I installed the trial version of Cubase 9.0.10 to determine why. That version of Cubase apparently has serious problems with delay instability in its triggering of VSTi’s form keyboard/controllers. I’ll look into that further and post another bug report to hopefully get that fixed too. :slight_smile:

unbelievable :unamused:
now please can someone close this thread allready because its complete nonsense

I have to ask. Apparently you did not see the VSTi triggering problem demonstrated in your posted test results. Can you see it now? If not, how hard are you trying?

You can find more details about that problem here: :slight_smile:

Explain to me: How is any of this relevant in a real project?

No One who uses Cubase the way it is designed for would run into any of your “Issues”. Because no one would have the idea of loop back record the monitoring signal of your VST instrument.

The only explanation to me is that you have absolutely no clue how to really work with cubase.
That would also explain why you havent answered my simple question yet

Also you mix things up all the time. Contradict you statements. Name things wrong. like in your new thread. In the very first sentence you talk about triggering external instruments. But in your test you use a VST instrument.

Either start testing stuff that is actually relevant for a proper use of Cubase or just stop posting bug reports that are meaningless

The relevancy of my suggestion regarding MIDI ASIO Latency Compensation was explained in my March 22nd post:

Although you apparently believe that would not be worthwhile, others may feel otherwise. (You need to remove the first “o” in “coockos” to un-censor the URL) Many are apparently even seeking out relatively expensive audio interfaces in their attempts to minimize their monitoring latency. Note that the audio interface latency now always added to MIDI inputs by Cubase can contribute quite significantly to overall monitoring latency.

That’s irrelevant. Again, as explained in the March 22, 2017 post:

Note that your use of it also quite effectively demonstrated the VSTi timing problem with Cubase 9 documented at: Apparently you were (still are?!) unaware of this problem!

I’m getting there! But please note that my primary goal is to help Cubase’s developers understand and fix the software problems as well as (hopefully) improve Cubase’s performance and utility for its real users (including my son). That’s why I took the time to submit these bug reports and plan to do so with other bugs which I’ve discovered in that process. I’ve had over 40 years of experience doing this type of thing.

From my March 17, 2017 post:

Back to the current post

Thanks for catching the error in that sentence – I fixed it. If you (or anyone else) have noticed other errors and/or inconsistencies, please point them out to and I’ll fix and/or clarify as necessary.

I’m posting things that should be helpful to the software developers for product debugging and improvement. My understanding that doing so through the forum is the correct way to do that. Do you think otherwise?

All irrelevant.
You cannot use something the wrong way produce strange results in the process and complain about it afterwards.

Your inability to understand issues doesn’t make them irrelevant. Saying that just demonstrates your inabilities and that you have nothing worthwhile to contribute to their discussion! Is this typical of your participation in forums? :wink:
in this post i showed you that ALC on midi works exactly as expected. It delayed midi by the outpul latency and the notes were mostly correct with a natural human variance. This is the purpose of this function in C8 and C9 and it works as advertised

You still believe that midi has to be compensated for the input latency of your audio interface. It doesn’t!!! Only for the output latency
Lets say you tap in the midi notes on the cubase click. The Click will be delayed by the drivers output latency so you will press the button too late by exactly this latency in reference to cubase internal time code. Now the audiorecording with your microphon will also be late by the output latency. The Audio Recording is than even further delayed by the input latency of your driver. Cubase now has to place that audio recording earlier in the timeline by the RTL.
Midi like i said is independend from the asio driver. We have tapped in the midi note late by the output latency because the click was allready delayed when we monitored it. PDC will add even more output latency so that this also has to be accounted for.
If the midi note would be compensated for the Input latency as well the notes would be placed too early. More precisely too early by the Input latency
Keep in mind that TRL compensation for the recording only effects the recorded media but not the monitoring exept PDC. thats why ALC has no effect during monitoring of your vst.
If you now play an instrument at high latencies on your cubase click you will have the playback delay on the click wich is your output latency. If you now tap on the click the audio of the instrument will be delayed by the output latency as well. That is difficult to play because the audio will be behind your click. by the output latency. Many people will than conpensate for that by pressing the button too early by the output latency to have the audio right on the click. And this is were ALC comes into play.

If you had used a plugin with latency (such as CurveEQ) rather than one that doesn’t (REVerence) your demonstration might have seemed more credible (but no less contrived). Why did you do that? :open_mouth:

Because it does add latency. You can give a crap about the plugin manager regarding latency indications. Why do you think the audio was shifted when i turned off the function if Reverence wouldn’t add latency by itself??

But interesting you skipped the post i actually referred to and instead came up with this one regarding record latency with plugins inserted in the input channels. Why did you do that? It has nothing to do with what i explained about ALC on Midi

you first approved this yourself when i first mentioned this and it made alot more sense to you. And now you desperately try to proof i am wrong?

I contributed with explanations of ALC and adjust for record latency with pictures.
You said you are no expert nor a musician nor an audio engineer who works with Cubase on a regular basis. You ask to be corrected when your conclusions are flawed or wrong. I tried but if you don’t believe me its not my problem.

Here is what i think. You think you made a great discovery here and you actually don’t want to understand it or beeing corrected for even you claim you do. What you want is to get credit for it but unfortunately you don’t get the credit you think you deserve. In fact i am the only person than actually corresponded with you here. Unfortuanely i don’t say what you want to hear. Again not my problem.

Seriously?! :open_mouth: The audio was delayed because you configured REVerence to add some “Pre-Delay”!

Unlike some other plugins, REVerence apparently doesn’t have any processing latency (“plugin delay”). It’s the processing latency (“plugin delay”) that gets compensated for by plugin delay compensation (PDC). The manual and you(?) say that “Adjust for Record Latency” should remove that “plugin delay” when recording too. In either case I don’t think most folks would be very happy if delays that they intentionally added were automatically removed by Cubase. :wink: It’s now even more clear to me that the state of the “Adjust for Record Latency” control has no effect – as originally claimed.

I now know that I was wrong. I can’t think of any use for the “Adjust for Record Latency” function as it is described in the manual. Can you (or anyone)?

With all due respect, you’re posts have clearly demonstrated that you aren’t nearly as knowledgeable on these matters as you think (and/or wish others too think/believe). However, I do appreciate your ALC pictures - which nicely demonstrated Cubase’s problems with VSTi triggering jitter. (And I did give you credit for providing them – thanks again!) But, it appears to me that your pictures regarding “Record Latency Compensation” were just misleading contrived nonsense! :open_mouth:

Haha. Seriously?.
If that shift would have been created by the pre-delay settings of Reverence than this shift would be in both pictures because the function compensates for plugin processing delay and not for pre delay settings of a reverb.
And for the record. I did set the Reverence to 100% dry. when i tested it. Why don’t you retry the test yourself Mister Super Engineer.?`maybe it becomes clearer to you because you obviously need the experience to even judge how things work.

You still refer to the wrong pictures. I dont talk about your nonsens test i made. I talked about the pictures i linked that explain when ALC is to be used and when it isn’t. You still don’t understand that midi ALC works exactly as intended. Even your starting post shows this. You don’t understand that ALC has only to compensate for the output latency because for VST Instruments there is no input latency to be compensated for. You also still seem not to understand that ALC is not for a technical compensation but for compensating the human nature of pressing the buttons too early. Exactly this i showed in my pictures i linked above
But isn’t it interesting that your topics have been moved to the Steinberg lounge.? So i am not the only one thinking you are dead wrong about this.

Word. :wink:

I don’t know where you found the time to even do the testing you did.

When recording/monitoring without plugin delays, I agree that both the click track and VSTi audio outputs will be physically delayed by the output latency of audio interface. If the software functions properly, VSTi audio outputs will also be delayed by the reported input latency of the audio interface - right? So, as you have pointed out, ALC would seem to be appropriate for playing to (right on) the click. But it wouldn’t be for what the manual claims (from Page 239 of the CUBASE PRO 8.5 Operation Manual):
If you perform a live recording on a VST instrument, you usually compensate the
latency of the audio card by playing earlier. In consequence, the timestamps are
recorded too early. If you activate the ASIO Latency Compensation button on the
track list, all recorded events are moved by the current latency setting.”

I apologize for my ignorance and incorrect statements regarding his Record Latency Compensation tests. For details, see

Why should the VSTi beeing delayed by the input latency? Only Audio that comes from the “inputs” of your hardware will be delayed by the input latency.

ALC on Instruments does exactly what i showed you in the pictures “Latency4.png” “Latency5.png” and “Latency6” and it works exactly the way it should.

Here’s what I actually posted - not what you quoted here :exclamation:

Cubase delays the recording of MIDI by the reported input latency of the audio interface to keep it synchronized with other audio inputs being recorded - right? It should also delay the triggering of the VSTi by that reported input latency to keep its audio output synchronized with other audio outputs when recording/monitoring - right? But, it would be nice to give users the option of disabling that added delay, wouldn’t it? :question:

If ALC’s purpose is to compensate for users playing to the click rather than the VSTi audio output as you seem to be claiming, then shouldn’t it’s description in the manual be changed to reflect that? :slight_smile:

What’s your relationship with Steinberg :question: