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).

I was really curious about this, so I decided to try it out myself anyway, and it's safe to say that my theory was wrong.

My Audio-interface is a Behringer BCA2000, by the way, but since the delay apparently happens with Echo and Motu devices, too, that does not really matter. With ASIO drivers, I get a mismatch between original track and bounced back track of around 9ms, regardless of the latency setting - with WDM drivers I get a whopping 37ms.

In other words: Everything that I record as overdubs to previously recorded tracks is off by 9ms. This is a real bummer!!!

As I see it, this should be relatively easy to fix, too: Cakewalk simply needs to add a user-configurable box that says: "Cut off the first xx.xx ms of newly recorded audio and move it to the left by that length".

It would be interesting to see other users' results here as well. For measuring the delay, I imported a drum loop that starts right on its first sample and bounced that to a second track externally. I then exported that second track, loaded it into Audacity (any other Wave editor will do) and highlighted the silence at the beginning of the Wave file to see how much there was of it. All in all, that took no longer than five minutes.

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...

regarding latency - when recording di'd guitars i can hear the difference between 1.5 (lowest i can go) and 6 ms of latency. and im no dennis chambers. (yes i know he plays drums:))



m

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!

Mildew and RTGraham

Thanks for the info and efforts. I knew there was a Pro Tools plug for older versions of PTLE. I don't know why it hadn't occurred to me to look for one for Sonar! [Dope slaps self!]

When I started this thread I was not completely sure that we were strictly talking hardware latency (it's -- as I measure it -- the extra 110 samples over the 128 x 2 that gives me 366 that threw me. If it had been an even 256, say, I would have added one and one, as it were and felt fairly certain -- and I have to admit, I thought somewhere in the barage of Sonar4PE marketing I immersed myself in, there was a phrase about "full delay compensation" that had led me to believe there was hardware comp).*

But I've become convinced that that's just what it is (or that that's part of it).


And thanks for the support on the "I'm not crazy I really can hear this" front... after I decided the right way to talk about it was to say "I'm just not a good enough guitarist to not let this bug me" people started cutting me a little more slack. (I can see why they might have thought it was a brag about golden ears.)

And, happily, the Sound On Sound article (link added to first post) gave me some support there, saying that singers can have a hard time with delays as low as 2 ms -- even though it said guitarists can often adjust for a delay as long as 10 ms -- and they cited the guitar amp 10 feet away example. (Which I admit, is one I've thought and thought about. All I can tell you is I never play with my amp 10 feet away if I have any choice at all. I'm not a good enough guitarist to play with my amp 10 feet away, I guess. LOL.)

Thanks again.

_________________

* One thing the SOS article talked about was zero-latency mixing. I don't know if he was correct, but as he described it, devices like our MOTUs use a bufferless internal signal routing that delivers a minimally delayed signal. But -- according to him (and it's a number I have read elsewhere in the past) all converters take in the neighborhood of 1 ms to perform A/D conversion and ditto for D/A. I didn't think the NZL monitoring on the MOTU took that long -- but even it is noticeable on the 'feel' level to me, so maybe so.

Anyhow, perhaps what we have here with the MOTU. Since the 128 buffers give us about 2.9 ms of latency, each, (and for this test we're using both recording and PB)... that gives us 5.8 ms of latency, right there. Then, if we add in 1 ms x 2 for actual conversion latency (using the SOS ballpark figures) we end up with 7.8 ms -- which is spitting distance from the 8.3 ms (or 366 samples) of 'track misalignment.'

So... that mystery looks pretty solved, I guess.

______________________________


And finally, back on the living-with-latency front, my "366 left nudge" system is working quite well. I make sure Num Lock is off when I start Cakewalk -- as it is WAY TOO EASY to accidentally hit a number key and nudge something by key-shortcut by accident. Then, when I'm done recording a track, I hit Num Lock, hit the one key where my first nudge value 'left' is, then immediately hit the Num Lock again. (Additionally, I have the other nudges both set to a full bar, so any accidental nudge will be immediately obvious. I hope. Heh.)

And, though I've (obviously) been worried about not knowing whether a track is nudged (since 366 samples/8.2 ms isn't a real long chunk of time, after all)... as long as I'm start my tracks on an even bar, the nudge is quite clear from MIDI position. I have my MIDI PPQN set at the high setting, 9 hundred something?-- and the nudge comes came out to 50 some ticks in a slow tempo song I was working on last night... and -- I LIKE this -- Sonar seems to 'exaggerate' the visual difference... so you don't even have to zoom in all that close to visually see if one clip is 8.3 ms ahead of another.

But I'm gonna look for a plug in to do this automatically. For sure.

Thanks again!

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.)

I tried loopback in Cubase SX2, using the default mains, at 100ms ASIO latency, same as my test for sonar.
70ms

I'm not sure, as SX2 turned out to be a waste of money for me, the old dog new tricks problem, but I remember a section in the manual about testing the latency for outboard hardware processor, and automaticly making the time correction. Someone really familiar with Cubase may be able to clarify if Cubase has a workable solution.


Edit: what did you find clumsy about nudge. It bothered me that there was no GUI with button and value to be adjusted.

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).

here's what i'm seeing with m-audio delta 66 card with the 5.10.00.0048 drivers on Windows XP Pro, Dell PC.

the setting is the card setting, the round trip is obvious the i/o in samples..., the measured is the sample offset with the initial track being "0" (actually i noticed it was 5 samples...) and the a/d-d/a is the difference between the expected round trip and the measured result - effectively the time spent in the external (omnistudio) wiring and a/d- d/a circuits... 78 samples on average although maybe 5-10 of these are SONAR...

setting roundtrip measured diff
1024 2048 2126 78
256 512 590 78
64 128 206 78

for anyone wanting to test this: i simple record a blank track then normalize it - it becomes noise... then output that to your d/a and back in through your a/d to be recorded on another track. then double click on the audio and zoom in fully so you can see the sample offset...

definitely a good reason to keep the latency as low as possible during tracking...

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 ! "