Correction/clarification (sorry!) - I should have said that having ASIO Correction ON “causes the recording of MIDI note inputs associated with internal instruments (Track 5) to be inappropriately delayed by the interface’s reported output latency” rather than “causes MIDI inputs associated with internal instruments (Track 5) to be inappropriately delayed by the interface’s reported output latency”. The “ASIO Latency Compensation ON.jpg” attachment shows that the internal instrument’s audio output is not delayed by the reported output latency during record, but suggests that it would be on subsequent playback.
I am not sure i can follow all this but i think you missunderstand the ASIO latency compensation for midi/Instrument Tracks. Its intended behaviour that the recorded midi notes are delayed by the output latency of your driver. I don’t really understand the problem.
Midi is totally seperated and independend from the Asio driver and can not been directly compensated by the ASIO Driver. Its a different system. Usually Windows Midi or DirectMusic.
And here comes the problem: with an output latency as high as 54ms you will surely notice a latency in monitoring your instrument when pressing a key to play it right?.
Usually you would subconciously press the key too early in order to hear the sound correclty in time wich is most probably the amount of your output latency. Since the Asio driver can not directly compensate the midi notes your notes will be recorded to early in the timeline wich would most problably be a time arround your 54ms of output latency. Now the “Asio latency compesation” will delay the recordings of your midi notes by your 54ms of output latency to compensate your early pressing of the key. that is all what it is.
I’ve tried to explain things more thoroughly. Please let me know if you (or anyone else) still think that my conclusions are flawed (or are correct).
The delay between the recording of the microphone taping the MINI key (Track 1) and the recording of the resulting MIDI note (Track 3) was ~4.7ms. Oscilloscope measurements indicated ~4ms delay between MINI key tapping and the MINI’s USB MIDI output signal.
The recording of the microphone tap (Track 1) was delayed by the input latency of the audio interface (SC) (reportedly 24.625ms). Cubase apparently delayed the MIDI note recording (Track 3) by ~24.6ms to help synchronize it with the microphone recording.
The MIDI note that was recorded on Track 3 also triggered a virtual instrument and was recorded on Track 5. The SC’s output of that instrument’s audio was externally connected to an input and recorded on Track 6.
The microphone’s output (recorded on Track 1) was monitored on another SC output that was externally connected to another input and recorded on Track 2.
The loopback recordings of the microphone tap (Track 2) and the resulting instrument audio output (Track 6) were delayed by both the output and input latency of the SC. These tracks indicate ~3 – 4ms of audio to instrument audio synchronization error.
If ASIO Latency Compensation was OFF during the recording, subsequent playback of the recorded tracks should maintain this level of synchronization between the audio tracks and the instrument audio tracks. That would be good!
If ASIO Latency Compensation was ON during the recording, the instrument’s audio output during subsequent playback would be additionally delayed by the SC’s reported output latency because its MIDI note recording (Track 5) was. Depending on the magnitude of that latency, instrument audio playback could be significantly delayed from that of audio recorded simultaneously with the instrument. That would be bad!
If the instrument player was compensating for the MIDI key - audio output latency, wouldn’t he/she compensate for both the interface’s input and output latency (its Round-Trip Latency [RTL]) rather than just its output latency?
Do all musicians monitoring through DAWs try to compensate for the audio interface’s RTL? (If that’s a stupid question, it’s likely because I’m an engineer - not a musician!)
I’m certainly no expert, but here’s what I think the “ASIO Latency Compensation” option should probably do.
For most users having it ON for all MIDI tracks by default would probably be wise to keep MIDI and audio synchronized. But, for those that want to compensate for it while playing (as suggested by Novikthewise as well as Propellerhead and Ableton manuals) or who want to minimize monitoring latency, it would be nice to have the option of turning it off on selected tracks.
For all tracks with “ASIO Latency Compensation” ON, MIDI inputs should be delayed by the reported input latency of the audio interface. MIDI outputs should be further delayed by the reported output latency. Tracks with “ASIO Latency Compensation” OFF should not be delayed. A good explanation of this in the manual would likely be helpful as well.
I’m not a musician or music producer (my son is) so I’m not sure if any of this is correct/reasonable. I encourage others with more experience to chime in.
The Asio Latency Compensation does not effect the monitoring of your Audio in any kind. It only effects the midi note positions right after you record them with a masterkeyboard or any other controller. I also does not have any effect on allready recorded midi track or synchronises audio and midi in any kind. It only comensates for your human nature of compensating latency yourself by pressing the notes earlier.
If at all Midi needs to be delayed by the output latency of your driver and not your input latency
Once again this function does Not effect the playback or the monitoring of any kind. Only the Note position during recording. Once the midi notes have been repositioned this function has no further effect.
As shown in the attachments of the first post, the only apparent impact of having “ASIO Latency Compensation” “ON” is that the recording of MIDI notes that trigger internal virtual instruments are inappropriately delayed by the reported output latency of the audio interface. Those attachments also show that MIDI inputs are always delayed by the reported input latency of the audio interface.
Reaper apparently also has problems with their implementation! - http://forum.coockos.com/showthread.php?t=188208 You’ll need to remove the first “o” in “coockos” to un-censor the URL so it can work.
Ok now i see.
Well aren’t you curious why the exact same problem appears to be in 2 different DAW. ?
I see now you use Asio4all with your onboard sound.
I redid your test and your system is flawed anyways. I have a dedicated audiointerface with a proper Asio Driver. When i do a loop back for audio what you did with Track 1 and 2 in your test i get a completely sample accurate recording with a buffer setting as high as 4096 and a RTL ( 92ms in/out)
There is an error in your Latency Compensation anyways. The looped back audio recording should be without any delay if the driver reports the correct latencies wich in your case is apperantly not the case.
I also did a pure midi to midi loop back. The recorded midi has a jitter of about 1 ms in my setup
Than i did a midi recording on an piano vst with the maximum buffer setting. As to be expected i will press the keys to early and the recorded midi is upfront. when i turn on Asio latency compensation the recorded midi is shifted by my output latency. Everything works like it supposed to here.
You are apparently having problems understanding what I have posted, I’m sorry for that!
Both Cubase and Reaper have problems with MIDI ASIO latency compensation, but they’re not the same problem!
I used a Roland Studio Capture (SC) with its ASIO driver for this (the Cubase) demo and ASIO4ALL with my computer’s internal sound “card” for the Reaper demo (to report erroneous latencies).
You apparently didn’t use the same procedure! The live recording of the microphone (first track) was physically delayed by input latency of the SC. The live recording of its loopback (second track) was further physically delayed by the sum of the SC’s input and output latencies. DAW audio ASIO latency compensation (or record latency (RTL) compensation) shifts all newly recorded tracks (live recordings) by the reported RTL to synchronize them with tracks being played back during the recording. Note that Cubase, like Reaper, is apparently supposed to allow that compensation to be disabled, but it doesn’t work in Cubase. https://www.steinberg.net/forums/viewtopic.php?f=253&t=111022
That’s because your first track wasn’t recorded at the same time as the second track. It was played back rather than recorded when the second track was recorded.
The SC’s reported RTLs are within +/- 1 sample at all sample rates and buffer sizes. I previously verified this by playing back a track containing a test signal thru single and double loopbacks.
Can you show me/us?
look its hard to follow your test. Yes its true. Cubase doesn’t correctly compensate the latency when you loop back record the live monitoring. Apperantly It only adjusts for the input latency in this case. But to be honest: This is a scenario that actually doesn’t really have any use does it? In my opinion its not intended to loop back record the monitoring signal. Thats why cubase doesn’t compensate. Loop back of allready recorded stuff works fine and also using outboard gear as external effects or instruments works without a problem here.
Also midi recordings that i do are right on spot.
Maybe you could expain what it is what you actually want to do with Cubase. Because i have the feeling you don’t use it like it is intended to?
Cubase doens’t allow to turn off latency correction for recordings alltogther. The “adjust for record latency” is for correcting plugin latencies of plugins that are located in the input channels of cubase. thats why you don’t notice any difference.
Sorry! Have you (or has anyone else) tried to work through it yourself? Have the Steinberg software developers done so? If not, will they? When? I’m quite happy to assist them in doing so if necessary.
Cubase appropriately only adjusts live MIDI inputs “in this case” (the test demonstration) by delaying them by the reported input latency of the audio interface.
The purpose of the test was to demonstrate how Cubase compensates for MIDI ASIO latency. I believe it does that and helped expose deficiencies in how Cubase does so.
When live recording and/or monitoring everything thru Cubase:
Audio track inputs (i.e. Track 1) are delayed by the interface’s input latency (by the interface). MIDI track inputs (i.e. Tracks 3&5) are delayed by the sum of the keyboard latency and the interface’s reported input latency (by the keyboards and Cubase respectively).
Audio track (i.e. Track 2) and internal virtual instrument audio track outputs (i.e. Track 6) are further delayed by the sum of the interface’s output latency (by the interface) and the sum of track plugin delays (by the plugins, = 0 in this test). Audio track outputs from external MIDI instruments triggered thru Cubase (i.e. via Track 3) will be further delayed only by the sum of track plugin delays. Since everything else will experience an additional delay equal to the output latency of the audio interface, the external instruments will be out of sync (sound early). Delaying the triggering of external instruments by the output latency of the audio interface would correct that.
When tracking while recording and/or monitoring everything thru Cubase:
Previously recorded audio tracks will be delayed by the sum of the interface’s output latency (by the interface), the sum of the track plugin delays, the track plugin delay compensation values, and the selected ASIO guard level (by Cubase). Plugin delay compensation should cause all tracks to experience the same delay as the track(s) with the largest plugin delay. This overall playback delay is analogous to simply delaying the playback/tracking session.
The playback of previously recorded MIDI tracks should trigger internal instruments without delay because the resulting audio will experience the same delays as the recorded audio tracks. But if MIDI ASIO Latency Compensation was active during the recording process, the resulting audio would inappropriately experience additional delays. This will happen because the MIDI recordings that trigger them were delayed by the reported output latency of the audio interface (Track 5). However, this added delay would be appropriate for external instruments because, unlike everything else, their audio isn’t delayed by the interface’s output latency. Like audio and instrument tracks, plugin delay compensation should be applied to MIDI track outputs to help keep external instrument audio in sync with other audio playback.
I want/expect software to function properly.
I’ll have to think about that one (no more time now)!
March 15 update. I’m afraid that I can’t figure out what it is supposed to do - sorry! Can you please provide a detailed description?
i redid your test and “surprise surprise” i came pretty much to the same test results. but i worked in 44.1 khz with a rountrip latency of 96.8 ms @ 2048 samples
The red shows your test with ALC turned off.
The orange shows your test with ALC turned on.
So what did we learn from this test?
Cubase dosn’t compensate for live monitored audio that is physically loop back recorded on a second track.
Dosn’t have to as this serves no purpose at all anyways
Also live monitored Audio from VST Instruments is not compensated when physically looped back on an audiotrack.
Midi Asio Latency compensation delayes Midi on VST Instruments by the reported output latency of the Asiodriver
(wich is the sole purpose of this function!!)
Midi Asio Latency compensation doesn’t delay midi on midi tracks that are not connected to VST Instruments
Wich is correct as its only meant for VST Instruments you have to monitor through your software
I still think you don’t understand the nature of this function entirely.
The Asio latency compensation on Midi is unlike the Plugin delay compensation inside Cubase a manual function that you have to decide wether it is applied or not. If activated on an Instrument or midi track that is connected to a VSTi it will delay the midi recording by the output latency of your driver. no matter it is appropriate or not. cubase doesn’t care. Why it isn’t applied to midi that is routed to an external Synth? Because everyone would use the pretty much latency free hardware monitoring of your Audiointerface instead the software Monitoring. And even if your use softwaremonitoring for that you wouldn’t work with such a high latency anyways as it is less than optimal. When i record midi i work with a latency of 4.2 ms at 44.1khz or evern less at higher Sample rates. It dosn’t really make a difference anymore if i turn on ALC or not with such low latencies.
All further scenarios are made with the same settings with 2048 samples @ 44.1 k and roundtrip of 96.8ms
So here is a scenario where you wouldn’t need ALC
What did i do here? On track 3 i placed a midi part with midi notes on the grid
i played the midi part back while physically looped back the midi through my midi interface from Track 3 to the Instrument Track (Track 5) and recorded it without ALC applied.
the result is a midi part that is pretty much identical with the source except a small jitter with up to 1 ms
The same scenario with ALC applied on the intrument track
As you can see ALC made exactly what it supposed to do but it was my own poor judgement to turn it on because ALC is not needed for incoming midi that is right on time.
to be continued…
Now here is the scenario that this function is specifically made for.!!!
Here you see me tapping in Midi Notes with my controller on the Cubase Click without any instrument as a destination so i could fully concentrate on tapping right to the cubase click. You see that even with an RTL that high i pretty much was in time with a natural variance of course.
Here you see me trying desperatly to tap in midi with an instrument as audio source on time. I loop recorded it till i adjusted myself for the latency so that the audio was on the click. Of course I had to tap the pad earlier due to the high latency setting.
Here i did the same as above with ALC turned on. Due to the diffucult nature of playing with high latency i also have a higher variance of course. With ALC on the Notes werent perfect but still much better placed than without ALC
but anyhow this function becomes obsolete as soon as you work at very low latencies.
To you last question:
Adjust for Record latency
Here i loop back recorded a played back audio track physically through an analoge loop back without any plugins in the input channel that is used as input for the second track (lower track). “Adjust for Record latency” has been turned off. I get a sample accurate recording. Cubase has correctly compensated for the RTL
Here i placed the REVerence in the the input channel that is used as input for the loop back on the second Audio track
You see that the plugin latency of Reverence has not been adjusted for.
Here the same as above with “Adjust for Record latency” activated
You still didn’t answer my quetion yet. Wanting Cubase to work properly isn’t much of an answer to that.
What exactly is it you want to do and were arises a Problem from what you have shown us so far?
Because you Test has no relavance if cubase is used the way it is intended to.
Your results suggest that Cubase 9 has even more problems with this issue than 8.5. Maybe you should repeat the test with 8.5 to see if something else caused the difference in our results.
The 48.4ms delay between your Tracks 9 and 11 suggest that your audio interface reports a 48.4ms output latency at that sample rate and buffer size - is that correct? The relatively short delay between your Tracks 11 and 12 suggest that your VSTi was inappropriately triggered immediately by Cubase when it detected the MIDI input. It should have been delayed by the reported input latency of the audio interface like the MIDI note recording was (Track 9) and my Track 6s were (https://www.steinberg.net/forums/download/file.php?id=19478 and https://www.steinberg.net/forums/download/file.php?id=19479). Your VSTi audio (Track 12) precedes your mic audio (Track 2) by your audio interface’s input latency (48.4ms)
The 18.4ms delay between your Tracks 2 and 6 suggest that, unlike Cubase 8.5, Cubase 9 has additional problems when ALC is OFF. Your VSTi audio (Track 6) precedes your mic audio (Track 2) by that 18.4ms
Out of curiosity, what audio interface and MIDI controller did you use?
From page 1103 of the Cubase 9 Operation Manual
“Delay Compensation Threshold (for Recording) Cubase features full delay compensation - any delay inherent in the VST plug-ins you use will automatically be compensated for during playback." Should that be corrected too https://www.steinberg.net/forums/viewtopic.php?f=253&t=113330
It actually delays that MIDI recording by sum of the audio interface’s reported input and output latencies (reported RTL). Why is it delayed by reported output latency? What is that supposed to do
If it was it could do something worthwhile
Do you think you “adjusted” yourself better because you had 48.4ms less latency with ALC ON than with ALC OFF? Isn’t ALC ON really ALC OFF
If it worked properly it could be useful even at low latencies. Hopefully you’re not saying it’s obsolete and should be removed because it’s too hard to fix
So when “Adjust for Record latency” is active, plugin delay is included in record latency compensation and is not included when inactive? When inactive, record latency compensation is determined solely by the audio interface reported RTL and selected ASIO Guard delay. When active, the track with the largest plugin delay determines how much extra delay gets added to the compensation – right? Pro Tools conveniently shows the individual track delays - can Cubase
Wouldn’t “Include Plugin Delay in Record Latency Compensation” be a better name than "Adjust for Record latency” for this option?
I would like to have the option of preventing Cubase from adding VSTi latency. IMHO disabling MIDI “ASIO Latency Compensation” on the appropriate track(s) should do that.
What translation software are you using? (from/to German?)
Well this is hopeless
You obviously didn’t understand a thing i wrote. ALC works properly. You just don’t understand how it works and when it needs to be applied. What you refer to on page 1103 has nothing to do with the Asio Latency Compensation on midi tracks. It has to do with “Constrain Delay Compensation” wich is a completely different function. As is the “Adjust for Record latency” function. You seem to have a problem to discriminate between these systems.
The Asio Guard Latency is no real latency that effects monitoring and playback and is not added or needs to be compensated during recording or monitoring. Here is the next wrong term on your list. In fact the Asio Guard Latency would be better called “pre-render buffer for non-realtime dependend Tracks”.
Don’t really know what your question about translation aims at. I don’t use a translation software.
But i am done explaining to you that your problem is no problem because it has no meaning. In fact i wouldn’t mind if the Midi and Audio in your test setup would be delayed by one hour. You also still evade my question what it is you really want to do with Cubase.
If all you want to do is creating routing scenarios that are not intended and complete nonsense and than wonder why cubase doesn’t work properly than you clearly should find another hobby as this is a waste of time than.
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
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!
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! https://www.steinberg.net/forums/viewtopic.php?f=253&t=111022&p=626711#p626711 Sorry!
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.
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. (https://www.steinberg.net/forums/viewtopic.php?f=253&t=111022 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: https://www.steinberg.net/forums/download/file.php?id=19479
My results with ALC ON are here: https://www.steinberg.net/forums/download/file.php?id=19478
Novikthewise’s with ALC OFF and on are here: https://www.steinberg.net/forums/download/file.php?id=20640
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.
now please can someone close this thread allready because its complete nonsense