• SONAR
  • Recording -- NOT monitoring -- latency
2005/08/06 21:00:05
theblue1
[ADDENDUM: I just came across this fairly thorough article on various aspects of latency that touch with specific sections on different software: Sound On Sound: Optimising The Latency Of Your PC Audio Interface]

OK... I'm afraid this is going to get lost in the sea of posts on monitoring latency/echo/etc.

This is not about latency when monitoring inputs.


The situation I'm experiencing is a a fairly lengthy (8.2 ms) delay 'in between' tracks. (Sonar 4PE.)


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

When I look at the two tracks, the beginning of the new track (Let's call it "B") is 366 samples (8.2 ms at 44.1, roughly) behind the postion of the beginning of track A -- but, to my thinking, they ought to be aligned.

But even if the position of the second track reflected monitoring latency, my monitor latency setting in Sonar is 2.9 ms. And this delay in getting the audio aligned into the track is nearly 3 times that.

So, is that a combination of incoming latency, outgoing latency and misc. processing latency? Or what? And if that's the case, why wouldn't sound cards with really long latencies, like, say, my auxilliary Soundblaster Live (love those Soundfonts!) produce unusably long 'track delays' to match their glacial monitoring latency?


[Now, I do know that this issue is not new. I tested my old desktop system with an Echo Mia PCI card and got, I think a 'track delay' of about 4.5 ms, or so.]


And, yeah, I know some folks will tell you 8 or 9 ms is nothing (it's the time it takes a sound to travel about that many feet at sea level)... but, well, dang it, it is something to me and I can hear it and it does screw with the feel (it's well into the time range where most people can begin to distinguish two independent sounds.)

If we can get plug in delay compensation, why isn't there some kind of way to automate a compensation for this very problematic delay/latency --besides manually nudging the clips? (Which is a pain in the butt if you start recording from zero and then, before you nudge, have to trim the beginning of the track.)

And I gotta say, as long as I'm opening up, that, as long as we've needed a sample-accurate nudge comand (thank you), that what we got was woefully underfeatured, uninformative [about its settings] -- and gives insufficient feedback if the nudge wasn't successful. Aside from that, it's great.

Anyhow, I can easily live with monitoring latency (my MOTU interface has a near-zero internal monitor that's fast enough for most use and I can always monitor through my analog board like the heavens clearly intended) -- and I DO have a nudge set up for precisely 366 samples (as long as I hit the right direction... er, the left.) But I just think that, at this point, we ought to have a way to more or less automatically record with our tracks properly aligned. Asking too much?


Anyhow... anyone have some insight into this issue?

Is there something stupid I've forgotten or that I'm doing? Is there some checkbox somewhere I need to check?


[PS... Love Sonar, don't let my tone fool you. Although I was doing this blindfold listening test with the same mix summed in Sonar and Samplitude and... well, never mind. Not here.]
2005/08/06 21:42:37
LoopJunkie
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.
2005/08/06 23:28:20
xackley
IOW, say I have previously recorded track A. I route that previously recorded track out the analog out and into the analog input of another channel (for example) and record it.


Why are you re-recording a recorded track. Are you still using hardware effects.

A recording from a mic/preamp will line up perfectly.
2005/08/07 02:12:24
theblue1
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?
2005/08/07 12:47:05
bermuda
It doesn't really matter.

What are you trying to achieve by this routing.

It's an interesting experiment, but what purpose does it have other than that.

Computer >>>D/A >>> A/D ...computer

Vs

Guitar or whatever > A/D .. computer

Why not just clone the original track or copy the audio clip into a second track ?


If you are trying to emulate some kind of hardware effect then there are ways of doing this in software.

2005/08/07 13:06:14
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
2005/08/07 15:06:29
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
2005/08/07 15:27:11
RTGraham
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.
2005/08/08 21:15:44
theblue1
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


What on earth would that prove?

If others say they can't discern a 10 ms difference -- that's not my concern. Trust me, some folks not only can, it can be the difference between a part being spot on or unacceptably sloppy, depending.

It is even a musically notable value, though admittedly a small one -- a quasihemidemisemiquaver (1/128 note) at 187.5 bpm.

Look -- I've been using Sonar since CWPA 6 in 1996 when I put together my first 8 ch DAW rig and I've bought every new Pro version since then except S3PE ('cause I knew I wouldn't have time to use it that year). Let me make it quite clear: I'm not trolling for a fight. This isn't about you. I'm not slagging Sonar. I like Sonar. Okay? Okay.


Whatever, I don't think it's unreasonable in the slightest to want your tracks to line up precisely. I'm not 'blaming' Sonar, here, I'm trying to figure out why it happens, fix that if possible, and if not, get on with using my nudge settings to, if not automate it, at least make it pushbutton. (Too bad there's not a good way of telling off hand whether or not you've already nudged a track.) It would be so nice if you could just automatically nudge the track, say, in my case, 366 samples left as soon as the recording ended.

C'mon, CW, what would that take, huh? A little auto-nudge? (Wink. Wink.)



Or, again, am I missing something here?

______________________

PS to the nice folks who can't figure out why I was doing this in the first place -- I thought I explained it pretty succinctly. IT WAS A TEST TO SEE IF THIS KIND OF TRACK-TO-TRACK LATENCY DID INDEED EXIST ON MY RIG. Sorry for shouting. Anyhow, it does. So...



2005/08/08 21:40:20
theblue1
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.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account