Recording -- NOT monitoring -- latency

I route that previously recorded track out the analog out and into the analog input of another channel (for example) and record it.

So you're going D/A and again A/D - that takes time ... and it varies between PCs and sound cards.

Sorry, I should have made it more clear that I was testing the track-to-track latency by doing that.

If the tracks playing back are considered the time baseline (as common sense dictates), we would expect, in a properly adusted recording system, that new tracks would line up with that -- that's a fundamental of multitrack recording. They should not be recorded, as they are in my case, 366 ms [Correction: 366 samples] late.

This track to track latency is easy to measure and easy, if ultimately tiresome, enough to fix by hand -- but that just means it's ripe for an automatic comopensation, ala auto plug delay compensation.


Let me ask you this, if you record the output of one of your tracks onto a new track, does it line up as one would like -- or is it late by a certain number of samples?

And, if it is, what do you do about it?

ORIGINAL: theblue1

This track to track latency is easy to measure and easy, if ultimately tiresome, enough to fix by hand -- but that just means it's ripe for an automatic comopensation, ala auto plug delay compensation.

Cubase has an external delay compensation function, so yes, it is more than ripe for automation in Sonar. :)

Bermuda: If you play along recorded tracks , you get the same latency as theblue1 is describing.

UnderTow

ORIGINAL: xackley

How on earth can you judge any real life input at a time level of 10ms or less. No one could accurately hit a cymbal or a drum within 10ms of accuracy. If you can supply a picture of 10 bars of human input that is always exactly 5 ms late I might believe it.
Then I would want to see the picture of them play back to the track create, to see if that track was an additional 5ms late. Then I would wonder if it was them waiting for the original to trigger the hit.

We need an atomic clock synced to Sonar and a sound generator to know if sonar is correcting for INPUT latency.
Don

Actually, I can show you MIDI drum tracks, recorded in realtime, that are consistently 11 to 13 ticks early because of the human ear compensating for 5.8ms softsynth latency.

Bearing that in mind, I agree with UnderTow that the real-world application of this test would be that if there is a loopback delay, then there is also a "play-along" delay, and in theory there should be a way to properly tune the software. It would have to be a system-by-system calibration, though, and I have no idea what would be involved.

ORIGINAL: UnderTow

ORIGINAL: theblue1

This track to track latency is easy to measure and easy, if ultimately tiresome, enough to fix by hand -- but that just means it's ripe for an automatic comopensation, ala auto plug delay compensation.

Cubase has an external delay compensation function, so yes, it is more than ripe for automation in Sonar. :)

Bermuda: If you play along recorded tracks , you get the same latency as theblue1 is describing.

UnderTow

Thanks. That's good to know. If Cubase is offering it, hopefully CW shouldn't be too far behind.

I was thinking that Digi had promised something like that in PT, as well. I'm not sure if they delivered.



As I mentioned earlier, the thing that perplexes me is why interfaces with really long latencies like old Soundblaster Lives (which I had some experience with in between 'real' interfaces ;) ) haven't exhibited a concomitantly worse performance in this respect.

BTW, it should be noted that I've experimented with different Sonar and device buffer settings. My current setting is 128 samples in my MOTU 828mkII and a 2.9 ms latency (playback buffer) setting in Sonar, the lowest I can go with my current rig. But I did experiment with several longer latency settings in Sonar (10 ms, 40 ms and 500 ms, give or take), with the notion that a bigger buffer might improve time alignment of tracks. But I got the same 366 sample misalignement each time.

I'm thinking 'misalignment' is a better way to talk about this, since that's really what I'm concerned about. Using the term 'latency' just confuses the issue, even if it's a generically accurate term.

I just want Track 2 to line up with Track 1.

_________________________________


And I seriously urge others to investigate the performance of their own rig, in this regard.

Remember -- what you're measuring here is the misalignment of newly recorded tracks vis a vis the playback of previous tracks -- the tracks which common sense will tell you are your timing baseline. If you record the output of previously recorded track 1 onto Track 2 and, when you go to play Track 2 back, it's x ms late that is an x ms misalignment. And in a properly designed and adjusted recording rig, tracks should not be misaligned. By definition.

<deleted by the poster>

Junski

Thanks a million for that info!

Twice I've tried to install the ASIO drivers for my MOTU 828mkII, but they haven't popped up (although the WDM and MDE drivers showed up fine). Maybe I'll just have to wrestle that to the ground.


j boy

Can you believe I had to look that one up? I knew it was hemi-demi-semi-something or other... and, actually, I was kind of shocked that 10 ms could be notated, myself.

It is a small amount of time, to be sure.

But I think a lot of us have sort of adopted the general societal view of a second as an almost atomic unit of time... but in terms of musical value, a second can be a very, very long time. It's two full beats at the relatively leisurely pace of 120 bpm. Or, to jump mindsets, here: one second equals about 103 feet on the freeway when travelling 70 miles per hour -- about 6 car lengths.


Anyhow, I've decided to talk about this in a different way. As I was about to jump into a thread on guitar amp simulators and plugs, I realized the best way to say what I wanted to say (to avoid trouble) would be to say: "I'm just not a good enough guitarist to play properly when the signal I'm listening to is noticeably delayed from what I'm actually playing at the moment." Or something like that. But you get the drift. Maybe that'll stop some of the "You think you can hear x ms of delay youre blinkin' nuts" sidebar issues... maybe. ;)

Thanks, man! The MOTU came with its own ASIO drivers which theoretically should have been installed by their install process, but apparently weren't (they've never shown up anywhere, anytime, anyhow.)


BTW... if anyone performs this 'test' on their machine, I'd be interested in finding out what the results were.

You know, this really is not some empty academic exercise. If your tracks don't line up right, that's a problem. By definition. If it's a big problem, you'll probably notice right away. But if it's a little problem you don't notice, it can still screw with you in subtle and not so subtle ways.

It's fine to say, oh, it's only 5 ms or 10 ms -- and if I use my initial drum track as a guide, none of my tracks should be more than that much 'behind' (which may or may not be acceptable to you).

But, say I put down a bass track, ref'ing my drums. It's aligned into the track 8.2 ms (366 samples at 44.1) 'behind' where it should be. Then I put on a clavinet part. Without realizing it, I key into my funky bass as my rhythmic guide. Now my keyboard part is 16+ ms behind the drums. Now, I lay down a funky fatbackin' rhythm guitar, trying to interact with clavinet part and using it as my rhythmic reference point. My guitar part is now a whopping 24 ms or so behind the drums... and that truly is a musically signifcant and noticeable amount of time.

Admittedly, this labored example probably wouldn't be reflected by real world experience, as the overdubber would be cueing himself off a matrix of those parts.

Still, since the parts don't line up, true rhythmic precision becomes impossible -- unless one manually adusts each new track to make up for the 366 sample misalignment (or whatever it is on a setup) of each new track.


Do folks see why this is a big deal?

____________

Now, if other people are not experiencing this track misalignment -- if newly recorded tracks align precisely with previous tracks and not x samples late -- it would be very helpful to me to know that, as it would indicate that there's something wrong with my system or set up.

BTW... several years ago there were a number of threads on the Digidesign boards about this very issue with their software/hardware set ups.

still haven't told us why you need to put your signal through a digital-to-analog conversion and then route it back through an analog-to-digital conversion, instead of simply bouncing internally in Sonar. This is not the recommended

I figured out what he was saying, and it makes sense.
My loopback from Output to Input back into sonar is 5ms.
Doesn't matter if ASIO latency is 2ms or 100ms. This is the time spent IN the A/D converters.

So I was playing to a click track, I would hear it 2.5 ms late

Then suppose I play a note, it is 2.5ms A/D conversion time late getting back to Sonar.

But, This would be true for all tracks recorded, it would not be cumulative. So. If every track recorded is the same 5ms late, then it is all in sync.

hmmmmmmmmmmm...

ORIGINAL: LoopJunkie
All this would only be true if you route each and every audio track - for whatever reason - out via a digital to analog conversion and back again through an analog to digital conversion.

That's what I thought as well, initially, but upon thinking about it, I have to admit that the original poster is right. Doing this loopback test should have the same result as recording a new track:

If the tracks that are being bounced back into Sonar are 8ms delayed, so will be anything new that you play simulatenously to previously recorded tracks. Until now, I always thought this problem had been adressed by Cakewalk years ago, because when I was recording with my Soundblaster Live! (which had a very high latency, along the lines of 150-200ms) and Cakewalk Pro Audio, there never was a delay (or so I thought).

I would have to physically rewire my setup to test this myself right now, but I'm thinking that this may be a question whether you use WDM or ASIO drivers: If you use WDM-drivers, SONAR first runs the Wave Profiler, which can take care of this issue (and which would explain why there never were any problems with high-latency-audio cards). With ASIO drivers, on the other hand, there is no Wave Profiler - in that case SONAR relies on the ASIO drivers to address the problem of delay recording delay.

@theblue1: Have you tried comparing ASIO and WDM-drivers for your audio card?

xackley and Mr. G

Thank you guys so much for testing this out!

xackley -- just as you note -- all the tracks are recorded with the same misalignment (vis a vis any previously recorded tracks). So -- as long as you're recording everything simultaneously -- like with a live band -- everything is cool.

It's only when you then go back to overdub that this misalignment rears its ugly head as a problem.

(And I am quite prepared to believe that it is, indeed, the sum of all my hardware buffers ... 128 twice for the MOTU and... another 110 somewhere... )

Also -- I want to make it very clear since it's apparent some folks are having a lot of trouble following me -- my example of each successive track in a one-track-at-a-time overdub project drifting farther behind is an extreme example that would probably never happen in real life, since most folks key would take their primary rhythmic cue from the drums (presumably the first track).

[Still, if the next track was, for instance, a bass, and you didn't adjust it, for sure, the bass would be x ms behind the drums (on my rig 8.3 ms at 44.1) -- and, there is a potential for subtle rhythmic confusion there. If a subsequent part cues off the bass, it ends up being 8.2 ms behind the bass -- but 16.2 ms behind the drums... yadda yadda. It's still not enough time for a cup of coffee, but the potential for a rhythmic vagueness is obviously increasing.]


Anyhow, it would be nice if I could just mark a check box somewhere and get Sonar to automatically realign each new track 366 samples left (earlier)... but I do have a nudge setup to 366 and as long as I don't click right instead of left (!) it's, you know, not that bad. (Although, because of the previously noted problem with left nudge and tracks tha begin at 0, I may have to change my work habits a bit.)

______________


On the test itself:

Actually, you can do the whole thing with Sonar (at least the last couple versions) since you can zoom in to sample level. Of course, you do have to route 2 of your outputs into 2 of your inputs.

If you try this test, please be very careful not to create a feedback loop. If you're uncertain or not confident about this, please don't do it. If you create such a feedback loop you could loose anything from your audio interface to your monitors to your ears (or any combination thereof).

Use a sound with a sharp transient that will be easy to find a reference point in. [It doesn't have to be loud -- probably best if it's not-- just a very fast transient so you'll be able to find a good, easy to find spot on the wave to measure from.]

Route your analog outs into your analog ins [did we mention the feedback issues already?] and record it onto a new track [do not turn on source monitoring! See dire warnings above].


Then use Sonar to zoom into both tracks, right down to the sample level. Find the beginning of the sound (or some other unmistakable reference point that can be isolated to one sample) and make a note of the sample number. Then do same in the second track. Subract one from the other. In a perfect system, they would line up. On mine, under a number of situations, with different Sonar 'Mixing Latency' settings, it always was 366 samples.

To find the time in seconds , divide the number of samples by 44,100. (Assuming, of course a sample rate of 44,100!) . In my case it was 366 samples divided by 44,100, which [rounded to 4 places] gave a result of 0.0083 [Carumba! -- I've been saying 8.2 ms through this whole thread, I think!] Which is, of course 8.3 ms.


______________


Finally, to those who don't "get" what I'm doing:

As I've said a few times -- this was a test. It was not some weird recording technique to see what an extra layer of conversion sounds like.

It was a test.

What was it testing?

It was testing whether or not newly recorded tracks are being properly aligned with previously recorded tracks. (It turns out they're not.)

Why is that a big deal?

Let's take it a step at a time.

Let's say I have a previously recorded drum (or any other) track in sonar on track 1.

I want to overdub a guitar, putting it on track two.

I roll Sonar. I listen to the drum. As I listen, I record my guitar.

But when I play both tracks back -- the guitar will be 8.3 ms (366 samples at 44.1 kHz) behind the drums. (Whether I'm on the money is, of course, a separate issue.)

How do I know it will be 8.3 ms behind where it should be?

Because I performed the test described in this thread.

Why did I test this in the first place?

I knew that this issue had existed in the past with CW/Sonar (as well as other software like Pro Tools LE). My old interface had only about half the 'misalignment' (about 4.5 ms) and I'd sort of let it slide a bit. But this problem was bad enough to become noticeable with the MOTU -- and I finally decided to see how bad it was.

As noted above, this is probably due to the (uncompensated) combined latency of one's interface's playback and recording processes, buffers, etc.

But in this era of plug-in compensation, not to mention phase-coherency conscioussness, this, too, seems like a good candidate for automation.


Anyhow, if you still don't understand, feel free to contact me at bluetrip.com/contact. (If you want me to email you back, check the box and leave a valid address. [You'll get an onscreen confirmation and a confirmation email if you left a valid address. If you don't, your message may not have gone through.] Cheers. )


______________________________________________________


Addendum: I'm just gonna add on to this post, rather than add another post and unduly float this thread to the top....

I thought this was an amusing illustration of this issue:

A few weeks back I was fooling around with BFD doing some fast, choppy funk. I remember laying down an electric guitar part that I thought had some moments and some fair stretches of pretty on the money playing -- but which was decidedly disappointing on playback.

I listened to see if there was anything I could slavage, looped four bars in one section that actually sounded pretty right and then saved it and moved on.

So, a few minutes ago I open it, play a 8 or 12 bars of the early part before the loop and say to myself, ugh, I thought I could play once.

And I think to myself, this was before I'd figured out the precise misalignment value that I recorded this. (And sure enough it still started at 0 with no slip editing which I would have had to imposed to get the wiggle room for the nudge.) Anyhow.

I hit my 366 left nudge button [conveniently and non-configurably labeled Nudge Left 1 (of Left 1-3, see)] and play the track from the top.

I'm floored. It's in the groove. (As much as we do these things around here, mind you.) It's hugely better.

But then I got to the section that I had previously looped... after the nudge, it felt just a bit forward, too edgy.


Another thing is that I've been thinking a lot now about the psychoacoustic aspect of these very short sonic misalignments. The next time I want to psychoacoustically place a sound in the back of a virtual soundstage, not only will I roll out the bass a bit and put on some extra long reflection 'verb -- but I'll also experiment with nudging the sound's clip back roughly a millisecond a foot for the distance I want to create. It only makes sense. OTOH, when the percussionists play in the back of a large orchestra they tend to compensate by playing ahead of what they hear from the front, cueing themselves, instead, from the visual signal of the conductor's movements.


And speaking of the speed of light. A lot of people think that's pretty fast...

ORIGINAL: j boy

ORIGINAL: theblue1
You know, this really is not some empty academic exercise. If your tracks don't line up right, that's a problem. By definition. If it's a big problem, you'll probably notice right away. But if it's a little problem you don't notice, it can still screw with you in subtle and not so subtle ways.
Do folks see why this is a big deal?

Unless I missed it, you still haven't told us why you need to put your signal through a digital-to-analog conversion and then route it back through an analog-to-digital conversion, instead of simply bouncing internally in Sonar. This is not the recommended way to work.

Actually, he has told you. He has explained quite clearly, more than once, that the real-world application of the results of this test is that most musicians' ears compensate for the hardware latency he has measured. In other words, if you record a drum track, then play a bass line along with it, the hardware latency created by converting the drums (on the way out) and the bass (on the way in) cause the bass to be recorded 366 samples behind where your ears told you it was (to use theblue's measured value as an example). In the real world, this can and does add up to perceptible differences in the groove.

This is indeed a real-world issue, and a documented one at that. The official term I've seen, which I used above, is "hardware latency." It's a separate issue from the software latency induced by the audio drivers or DAW application, and Cubase has claimed to have an effective compensation mechanism for it for quite a while now - at least since we were on SONAR 3. Not having used Cubase myself in many, many years (back when it was known more for crashing than for playing), I can't say whether or not their system works well; but it certainly would be nice to get some kind of implementation in SONAR as well.

And yes, I did measure it on my system as well. I find it interesting that theblue and I are both using MOTU interfaces (mine is a 2408mkII), and our hardware latency is almost identical - same converters, perhaps?

Finally, it occurs to me that before software applications like SONAR had automatic plugin delay compensation (PDC), certain plugin manufacturers created "delay compensation" plugins to insert on a track with any plugins that caused a delay, effectively shifting that track by a certain amount. UAD, for example, had a delay compensator available, and I think AnalogX made one as well (but maybe it was another company). This might be a better interim solution than having to nudge with no visual feedback.

EDIT:
I just double-checked AnalogX's SampleSlide plugin (http://www.analogx.com/contents/download/audio/sslide.htm) - it appears to only be able to shift a track to the right, which doesn't really help here. If anyone finds one that can shift in negative sample values as well, please post here!

I thought it was worth updating this thread.

I had said above that I'd been told that a couple of other DAWs did have an automatic conversion/latency/track misalignment compensation function.

As far as I can tell at this time, none of the major players and no minors I know of have such a compensation. (I'm not absolutely sure about Samplitude and I'm sure you'd know what I mean if you spent any time at their site, but it didn't look so. Of course, all the major sequencer DAWs except for Pro Tools LE now have plug in compenation.)

Anyhow, thank goodness for Sonar's nudge command -- but, gawsh, who the heck designed that thing? It's so 1987... completely user unfriendly.


As noted, my source on PT LE was incorrect about LE's compensation capabilities, and I was able to explore that a little when an 002 user in another forum reported something like 40 ms track 'misalignment' when she did the test above (she'd done it on her own because she could pretty much hear the problem outright and tested it to see just how misaligned it was.)

Anyhow, it's good to know, in a perverse way, that it's apparently not a matter of Sonar lagging the pack.

OTOH, it'd be nice to not have to nudge this by hand. As was noted in that Sound On Sound article, monitoring latencies as little as 2 ms can throw people off. These might be tiny values, but they are significant. A quasihemidemisemiquaver, remember? (Or whatever the heck it was.)

This subject has been covered last year in the forum. Here's the link.

For the record, my own latency is 128 samples (Echo Mia, WDM drivers).

Just to add my 2 cents about this :

I use a Frontier Design Dakota-Montana (PCI Cards) setup, along with Sonar 4.04. The beauty of the thing is that there is NO AD/DA conversion process into these cards, as they rely on external converters. Mine are 4 ADATs, that I use for 32 channels of audio routed to the mixing console.
This means that the assumption about AD/DA processing adding time to the RECORDING process is false. See below...

Since I experienced these problems, either with SOnar 2,3 or 4, I've also noted that my delays were far from being consistent... And I hit marks as high as 50 ms and as low as 2ms ! Instinctively, I performed the same test you did, in order to take measurements of these lags... Again, since I am basically doing my rerecording loop with Lightpipes, I keep my signal in the digital domain, running from output to input at lightspeed. As far as I know, the computer is free of anything that is not ausio and Midi. No firewalls, minimal internet, no mail or active antivirus and NO active process in the background. It boots in 10 seconds from power on...

The tests some have made here seem to indicate that this should be a common issue for everyone... Apparently, in another thread, a poster has just solved his problem by changing his current audio interface for a Layla 3G. After he made some measurements and started a thread to explore the situation, without success, he wrote that he had no more time delays into his audio in Sonar after installing the Layla...

This let suppose a couple of things :

This is not Sonar... (not sure)
This is not the OS (unless compatibility probs)
This may be the Hardware ( in that case every M-Audio interface, let's say, should exhibit the same "performance")

This may be the drivers (And now, what can we do ?)

I've found interesting to note that many didn't care about the exact timing replication of their perfomances, here. Me, it just makes me wanting to get back to my ADAT setup circa 1994... I recently recorded an album for children with a singer... signing intentionnally sloppy... but everything else was sequenced. Problem was that the guy's voice seemed to never sit at the same place, from a playback to another.

On one particular song that had a swing feel, I wanted to record the output of the percussions to a wavetrack in order to apply some sonic treatment... No more swing ! The triplet eight note has turned into a quasi 16th note... This just means that nothing recorded into that system will ever playback the same way it was performed.

So, I am lost for the moment... I just wanted to share my observations about this issue. I hope someone will come up with a generic and technically viable solution. Otherwise, it is just taking out the last chunks of fun I had while recording music, replacing it with constant fear of failure.

"Yes, I gues this take was in the pocket... but we'll never know ! "