That test procedure measures record latency, the offset on the timeline between earlier tracks and a new track played to them. That should be compensated automatically by the DAW if it senses the round trip time correctly. In that case it simply places the new recording on the timeline where it belongs. If the measurement is wrong then each new track is a little later on the timeline, and things get bad real fast. There's generally a manual setting in the DAW for record latency correction.

Input monitoring latency is a different thing. That's the delay between the time you play something (while tracking) and the time you hear it. If you go through AD and DA conversion there is some latency, though it can be quite low if done right. If the input monitoring path is all analog then there is no latency. If you use your interface's DSP input monitoring facility then latency should be very low. I know there are people successfully monitoring live through their DAW, but that's going to be the highest latency of all. It can still be low enough, but the more processing you do the more time it adds to the delay.

Midi has only limitations based on available channels. Latency is a purely audio issue for your purposes:).

Makzimia, post: 454950, member: 48344 wrote: Midi has only limitations based on available channels. Latency is a purely audio issue for your purposes:).

Well, yes and no. ;)
If you are sending a midi signal direct to a track without it triggering anything internally, then yes, it should be virtually immediate ( other than the microsecond delay that some people can sense, like Donald Fagan for example, who claims he can hear the delay with midi...)
But if you're triggering internal samples (VSTI'S), You can get latency on the audio playback of a certain sample, depending on your audio interface's limitations and the buffers you have set in your DAW.
And, some softsynths can have their own internal buffer settings as well, although that's not quite as common as it used to be on older systems and versions, but it's still possible to see them. NI's B4, and Garritan collections do have internal buffer settings within the sample player itself that you can adjust along with your DAW buffer settings, though these days I'm fairly certain that the DAW settings over ride the softsynth settings.
FWIW :)
-d

DonnyThompson you’re still in audio :). The actual transmission of midi signal has little to no latency compared to audio.

Makzimia, post: 454953, member: 48344 wrote: DonnyThompson you’re still in audio :). The actual transmission of midi signal has little to no latency compared to audio.

DonnyThompson, post: 454952, member: 46114 wrote: If you are sending a midi signal direct to a track without it triggering anything internally, then yes, it should be virtually immediate ( other than the microsecond delay that some people can sense, like Donald Fagan for example, who claims he can hear the delay with midi...)

;)

Ok ok... my bad. But still, for MOST purposes, midi itself is not an issue for mere mortals :). Lol.

Interesting.
But setting up latency manually is dangerous... Many daws will exhibit more latency when the mix is more busy (more things to compute).
For exemple if I play guitar through a real time amp sim on a blank project, with sonar at least, I'll get no latency that I can hear. But then if I'm on my 3rd amp sim and try to play again, the delay makes it impossible to play in time.

The same will acure with a VSTi.. if you play a piano with thousands of samples. It will run fine when not much is going on in the project but make lag if the project is very busy.

That's why I rely on the real time mixer of my interface so much. I'd rather hear the clean sound of the guit while recording and then put the distortion afterward.. Of course nowaday, I record my Vox AV60 and a DI signal at the same time .. So it's not a problem.

pcrecord, post: 454956, member: 46460 wrote: But setting up latency manually is dangerous...

I was talking about manually adjusting record latency, not input monitoring latency. If you're using amp sims in real time then you're talking about input monitoring latency, or input to output time.

Record latency is purely a matter of output to input round trip time. The DAW is in control of the playback buffer so it can account for that, but from the DAW through the interface is out of its control so if it doesn't measure it accurately you have to do it manually.

I get what you are saying.. but my point was that maybe (this is to be tested) maybe the latency varies due to how many operations the DAW has to make.
I might be wrong of course...

I'm going to revisit this thread after doing a few experiments and getting some screenshots to show results because I really want to nail/own this.

What I know and want to test:

1. My DAW plays a click source (self generated midi?) --- it goes out using my interface to my headphones. This chain would have an element of Output Latency -- similarly if that signal chain was a speaker and I was in a chair listening there's be an additional latency there before my ear heard and reacted to the sound.
2. If I take that same signal from the OUTPUT of my DAW and loop it into an input and record it I can measure that signal and that signal captures both the OUTPUT latency but also the INPUT latency for something we'll call ROUNDTRIP latency. I can measure this by comparing my click source to the recorded loop in my DAW
3. If I run this same loopback click source through my guitar amp sim (guitarRig) in my DAW and record it I can see how the plugin might affect latency of the signal by doing the same comparative measure of the wave file.
4. If is also send a WET signal of #3 to a bus and record it, I might also capture an approximation of any additional recording monitor delay as part of my latency equation?
5. If I take that same Wet Signal from #3 into a bus and route that bus to the output of my interface and back in to a new bus (INPUT) might I also capture an element of recording monitor latency?
   Assumptions:
   • When you adjust latency inside your DAW - you want to account for roundtrip latency (if you are playing to a click or other tracks) because these factor in the latency equation. It's not just INPUT latency at play - OUTPUT is at play as well.

   Although my DAW has a manual adjustment field for both INPUT & OUTPUT latency -- Output latency is impossible to quantifiabley measure so you adjust for Input using the above methods as captured in #2

   Currently my DAW reports my latency to be 4.6ms ----- before making some settings adjustments to my computer it used to report latency at 7.5ms --------- My manual measured latency ROUNDTRIP was 644 samples or approx 15 miliseconds. I will redo all the tests and check my methodology and report back.

I'll follow that with attention ! Thanks for doing this

My feeling is that, provided your DAW knows what type of audio interface your are using, you should be setting the output latency to auto, at least for these tests. In that way, the DAW will pre-advance the output play so that the timing at the interface connectors will be exact. This means that you do not have to worry about or adjust any latency for overdubbing, and it will compensate for using plug-ins and other time-consuming digital processes on the input and output routes.

If your DAW does not know about individual interfaces, you will need to find out what the delay figures for input and output are (e.g. from USB to XLR and v.v.) and add those manually to the DAW compensation times, still keeping the setting at auto (if possible).

What any DAW is not going to be able to help with is real-time processing effects. So, for example, if you are hoping to use your GuitarRig ampsim while tracking, you are always going to have latency between the rig input and the monitoring output, simply because the effect generation process takes time. In the few occasions that I've had to record a player who insisted on having digital effects present while tracking, I've wheeled up a second DAW to run a minimal version of his amp sim and whose output is fed into a mixer along with the main replay tracks to go to his phones. The input was T-ed off the guitar lead. The real effects were then applied at mixdown.

I've blown my own mind here doing tests....

What I've learned so far:

1. My Interface has latency -- when I measure Roundtrip latency (comparing a recorded waveform to the internal click-source inside the DAW) it appears to be 390 samples latent (via roundtrip routing click-source to a hardware output, looped back into a hardware input and recorded in the DAW).

2. My Interface reports and adjusts latency slightly greater than the actual latency (it adjusts in by 410 samples) so anything I record is slightly rushed when adjusted (which is what I've been feeling this whole time and confirms some of my frustrations) Interface reports around 4.6/4.6ms (which I think is assigning 4.6 to both input and output for a total of 9.2?) --- not sure what it actually adjusts though but it puts the waveform slightly before the beat (about 20 samples) which is almost exactly the difference between the reported latency and my actual measured latency. (I measure 390 it adjusts 410 on auto).
3. By manually adjusting the latency inside the DAW using my measured number I'm still slighting before the beat -- ie - to be on the beat I'd need to adjust less than I measure. That means to be on the beat I need to adjust both less than reported latency but also less than my measured latency --- this tells me that the adjustment calculations going on inside the DAW are more complex than I am aware.
4. The use of an amp sim does not in and of itself add latency to the chain as far as I can tell in terms of capturing the dry signal.
5. When taking into account real-time monitoring/recording using amp sims, there does appear to be a tiny bit of additional latency in my chain -- I routed and rendered to a new track (through the interface) a signal that was dry (with FX off) the again wet (with Fx on) The wet signal out the interface and back into a 3rd track --- I get the smallest change in wave form timing (like 53 samples). This means my ears are hearing a 50 sample delay when I track...
   I wont post screen shots yet because I need to replicate these tests and results now and look for any flaws in my process that I might be overlooking. I probably did 40 different tests....

   My head hursts

I once had a glitch that messed with the automatic latency detection. I went through much of what you describe, then the problem vanished after a reboot or two and I just reset it to auto.

I would like to know if the latency is the same on a full blown mix as of a project with just a few tracks.
If you ever get the energy to test this that would be very informative !

Does output latency really matter? . As long as you monitor yourself before you go in to your daw you will be fine.
If your daw had a huge output latency , then you would play your lines with that latency as you hear it anyway which nullifies that prob.
Am I missing something here ?

Smashh, post: 454998, member: 45856 wrote: Does output latency really matter? . As long as you monitor yourself before you go in to your daw you will be fine.
If your daw had a huge output latency , then you would play your lines with that latency as you hear it anyway which nullifies that prob.
Am I missing something here ?

It mathers when doing roundtrip, like reamping a track through external hardware... ;)

ooh , thanks Marco(y)

I have come up against that and shifted the tracks after they were recorded which is a pain in the butt ,
Now I don't reamp ...lol ( try to get it good first time in :whistle: )

Smashh, post: 455000, member: 45856 wrote: I have come up against that and shifted the tracks after they were recorded which is a pain in the butt ,
Now I don't reamp ...lol ( try to get it good first time in :whistle: )

I'm right with you on that ! ;)

Smashh, post: 454998, member: 45856 wrote: Does output latency really matter? . As long as you monitor yourself before you go in to your daw you will be fine.
If your daw had a huge output latency , then you would play your lines with that latency as you hear it anyway which nullifies that prob. Am I missing something here ?

It matters only if you monitor through your DAW rather than direct through the interface.

pcrecord, post: 454999, member: 46460 wrote: It mathers when doing roundtrip, like reamping a track through external hardware... ;)

Boswell, post: 454990, member: 29034 wrote: ... provided your DAW knows what type of audio interface your are using, you should be setting the output latency to auto, at least for these tests. In that way, the DAW will pre-advance the output play so that the timing at the interface connectors will be exact. This means that you do not have to worry about or adjust any latency for overdubbing, and it will compensate for using plug-ins and other time-consuming digital processes on the input and output routes.

Re-amping works the same as overdubbing (tracking) in timing terms. Think of the guitar amp as a box listening on headphones to the already recorded raw guitar signal and then playing along to it in a distorted way. If your DAW can overdub correctly by time-advancing the output tracks, it will work when re-amping.

If your re-amp loop includes pedals, some people add more output advance to compensate for any delay through the pedals, but this is correcting for a delay we would not be conscious of when playing live.

pcrecord, post: 454999, member: 46460 wrote: It mathers when doing roundtrip, like reamping a track through external hardware... ;)

Plus I think the output latency of something like a click track (or your midi drums or whatever you are playing to) is part of the human latency equation - you sync your playing to and in anticipation of the click so if you are monitoring it or playing to it through say your headphones it accounts for the latency.... I'm curious about output vs input though because I can manually adjust for both in the DAW but I'm not sure how the math on the auto adjustment works.

I'm now going to add that I am very deep in the rabbit hole and this exercise has really opened up my understanding of both internal and external routing in REAPER and with my interface and questions relating to latency..... I'm building a very detailed set of wave comparisons that I think will be really revealing -- will post them for sure (but again - still checking all my methodologies for errors and incorrect assumptions)

Here's an image I hope shows some simple comparisons....

Track 1 is the click-source
Track 2 is: Click-Source----HARDWARE OUTPUT-----HARDWARE INPUT (with zero latency compensation) showing actual ROUNDTRIP Latency. Latency measured at 383 samples
Track 3 is: click source---INTERNAL send/receive (no latency compensation)----- note it lines up with no deviation in time from click source basically confirming zero latency for DAW send/receive buses
Track 4 shows: Click-Source----HARDWARE OUTPUT-----HARDWARE INPUT (with interface reported DAW managed auto adjustment). Note that the wave form is actually 21 samples Ahead of the actual beat meaning that the auto adjustment over-compensated for latency
Track 5 shows: Click-Source----HARDWARE OUTPUT-----HARDWARE INPUT (manual latency adjusted to 383 samples) - Note that it lines up perfectly to the click source.

More complex comparisons to follow showing other elements affecting latency (including more complex routing, FX usage etc....)

Attached files

Here's where it starts to get interesting... This next photo shows the comparison between the click track with active FX, and the bust where the post FX signal was sent and recorded. Not sure how to interpret this but I think it shows that the latency in the FX is 17 samples? Or is it larger? Thoughts?

Or is it more like 30 samples... not sure where to measure the wave

Last test ---- I rendered a track w/ FX to compare with the recorded FX send on the bus to see if any compensation was being done in the DAW on rendering for the plugin being active -- it was identical to the bus so the answer is no. screenshot...

So the next test would be to duplicate these test on the bottom of a very large project to see if that changes anything....

It's looking like for my DAW I should manually adjust the tracks by 383 + 29 (it was 29 not 30) samples if I'm playing Through FX like guitar rig

So last one here showing all the tests comparatively and the inclusion of Drum Midi from Superior Drummer in testing...

Track 11 is a recording of the internal audio sends of the Midi Drum (snare hit, combined samples from two tracks on the beat w/ no processing) and interface reported compensation
Track 12 is the same as above with Zero compensation
The two tracks are identical on the timeline. What's unknown is how much lead time exists in the snare sample transient . What this tells me is that there's no compensation occuring for midi when rendering happens or when internal sends are recorded.

Tracks 13 & 14 are individually rendered from the two tracks that comprise the sample snare sample -- rendered separately to allow me to see the transients better.

There's either a 10 sample delay on the midi OR there's a 10 sample lead time on the midi before the beat

OVERALL CONCLUSION:

1. On RAW audio inputs with no FX processing active on a track the interface reported latency adjustment pushes the track a little too far ahead of the beat (early) for my liking
2. On audio inputs using FX processing, the interface reported auto adjustment is pretty close to perfect as the extra delay pushes the track audio almost perfectly back to the beat in terms both for what I'll call live monitoring but also when rendered.
3. Midi drums seem to have little to no latency and the VSTi itself seems to cause little to no latency... latency exists in the yet to be measured OUTPUT element because it's only half the roundtrip. I predict that all my drum hits will still be slightly ahead of the beat --
4. That when tracking with VSTs or VSTi's, it's always best to track along with rendered takes as opposed to takes still to be rendered to avoid mixed latency issues or the compounded effect of CPU and resource usage outside the scope of these test...
5. I learned a lot about inputs and outputs in my DAW and interface.... and my conclusions are all slightly suspect given that this is unproven and comes from a single attempt to understand this. ie -- little "c" conclusions not big "C".