I've been having all kinds of issues with timing as I record that I've basically realized are latency issues.
(Using Reaper and an M-Audio Profire 610)
So I measured my latency as follows:
1. Inserted a click source in my DAW
2. Sent that signal through the output of my interface looped back into my input and recorded it
3. I then measured the distance between the click source and my recorded click source (in sample units) and determined what my round trip latency was/is.
4. In my DAW I override the internally reported latency from my interface to set it manually the number of samples I measured as my latency.
Now if I'm right about this, it captures and accounts for roundtrip latency - that is to my ears from inside the DAW then through my interface, and the latency involved in my guitar signal going through my interface and being recorded by the DAW.
If I wanted to more specifically account for any specific latency caused by plugins etc I could do that same loopback test but run the click through those plugins as well to see what they might be adding to the issue.
I also guess that if I'm listening to my instrument through live record monitoring, my brain would be dealing with an additional bit of difference between the click source in my ear and the recorded monitored output of my guitar and could account for some performance issues.
Where I get less clear is with things like midi-tracks etc... Does latency on midi also get compensated for by my DAW ? Is midi latency different than my other audio interface latency measurements.
With respect to midi -- (like a sequence or a drum beat) - should I always send it to a bus to be rendered/recorded as an audio track. If so -- won't this audio only have half the latency of the tracks (given they are not dealing with the return leg of the latency equation)?
Thanks guys -- just really trying to get my head around this and really tighten up my workflow so I can get better recordings in the can.
Comments
That test procedure measures record latency, the offset on the t
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 i
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 limit
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 transmissi
@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’
;)
Ok ok... my bad. But still, for MOST purposes, midi itself is no
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... Ma
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 late
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
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 a
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:
Assumptions:
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
I'll follow that with attention ! Thanks for doing this
My feeling is that, provided your DAW knows what type of audio i
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 s
I've blown my own mind here doing tests....
What I've learned so far:
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 detec
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
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 you
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 r
It mathers when doing roundtrip, like reamping a track through external hardware... ;)
ooh , thanks Marco(y) I have come up against that and shifted t
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 agains
I'm right with you on that ! ;)
Smashh, post: 454998, member: 45856 wrote: Does output latency r
It matters only if you monitor through your DAW rather than direct through the interface.
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 doi
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
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....)
Here's where it starts to get interesting... This next photo sho
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 w
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 reco
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 inc
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: