Recording -- NOT monitoring -- latency

RE: Recording -- NOT monitoring -- latency (Mr. G)

Fri, 10 Mar 2006 01:34:57 GMT

ORIGINAL: jlgrimes
And someone wondered a practical reason for going out of your d/a converter and back into your a/d converter.
Sometimes people want to run their softsynths through hardware (preamps, compressors, outboard digital stuff etc).

That is one explanation why that delay matters, but strictly speaking, the issue occurs even with you want to do plain and simple overdubs of audio tracks - the loopback test just proves that there is a problem.

It sounds like you want a perfect solution though. I would think if they could just get the offset to a minimal point (under 3ms), most people would be fine and there would definitely be less complaining.

Who wouldn't want a perfect solution. :) Surely a small enough latency along the lines of what you have described would be acceptable, but that can probably not be achieved by Cakewalk because it is largely up to audio drivers. What could be done, however, is introduce a compensation mechanism as described earlier (essentially an auto-nudge feature for all new tracks), which would at least help those who experience a constant delay.

I think this problem also hits people who do a mixture of midi and live the hardest.

Or for anyone who needs to do overdubs of any kind.

Regards

jg

RE: Recording -- NOT monitoring -- latency (newfuturevintage)

Thu, 09 Mar 2006 14:33:33 GMT

ORIGINAL: tunekicker

If you know the delay you get in terms of samples (I believe blue's was 366?), then using presets and Voxengo Latency Delay will help you correct these errors quickly. I would insert this on all overdubs and Apply FX before doing any other mixing.
Peace,

Hi Tunekicker...I was just thinking about this and think it's the other way around. I could be wrong, but here goes:

The Voxengo Latency Delay reports a delay the PDC mechanism to advance audio for VSTs that don't report their inherent latency. Applying this to overdubs would actually double the error.
But putting it on the guide tracks during the overdub, then bypassing it afterwards should achieve what you're talking about.

Probably the easiest way to do this if you've got more than a few guide tracks would be to select all guide tracks, then bounce these to a new track before overdubbing.
On the new bounce track, apply the Voxengo Latency Delay to your necessary value and monitor only this while overdubbing.
After overdubbing, mute the bounce track, and return to monitoring the original guide tracks.

I'd think creating two busses, one Master, and one Overdub Guide with their Mute buttons latched in opposite states would further simplify the process.

Egads. This is way more convoluted than I'd hoped for " />

.

RE: Recording -- NOT monitoring -- latency (TwentyTimesSeven)

Wed, 08 Mar 2006 01:33:31 GMT

ORIGINAL: tunekicker

If you know the delay you get in terms of samples (I believe blue's was 366?), then using presets and Voxengo Latency Delay will help you correct these errors quickly. I would insert this on all overdubs and Apply FX before doing any other mixing.
Peace,

Thanks TuneKicker.

But I think I'll pass and leave well enough alone.

Two samples is the "round-trip" time. It's not a configuration I require often.

20x7

RE: Recording -- NOT monitoring -- latency (tunekicker)

Wed, 08 Mar 2006 00:50:35 GMT

If you know the delay you get in terms of samples (I believe blue's was 366?), then using presets and Voxengo Latency Delay will help you correct these errors quickly. I would insert this on all overdubs and Apply FX before doing any other mixing.
Peace,

RE: Recording -- NOT monitoring -- latency (TwentyTimesSeven)

Wed, 08 Mar 2006 00:37:40 GMT

ORIGINAL: jt

TwentyTimesSeven, Thanks could you try the test again in WDM mode?

Loopback Test Instructions

Here's another thread talking about the same issue

Hi Jt,

"WDM" is not available to me.

I did the test again. "WDM/KS" selected. I used the provided .WAV, 44.1khz/24

I got the same result: Two samples.

For the "sanity check" I disconnected the patch cord and tested again. I recorded the expected flat-line.

I think I'm doing it right.

I'm using the version 2 UA1000 drivers (not the 64bit OS drivers). Also, contrary to Sonar documentation for AUD.INI:

Use24BitExtensible=0

It has been my experience that bad things happen if this is set to 1.

I'm curious as to why others are not reporting similar performance.

Stuff: SP2, UA-1000,Ver 2 drivers, S501PE.

20x7

RE: Recording -- NOT monitoring -- latency (jt)

Tue, 07 Mar 2006 20:45:29 GMT

TwentyTimesSeven, Thanks could you try the test again in WDM mode?

Loopback Test Instructions

Here's another thread talking about the same issue

RE: Recording -- NOT monitoring -- latency (jlgrimes)

Tue, 07 Mar 2006 20:09:16 GMT

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

I think the root of this problem is there are so many sound cards out there where the implementation isn't the same.

On my Echo layla 3g, WDM only produces a small amount of offset <2.9ms, which I can't hear. I agree with you when you say 8 ms is unreasonable.

ASIO on my Layla produces a considerably larger and audible amount of offset (it actually plays the recorded track back early.).

And someone wondered a practical reason for going out of your d/a converter and back into your a/d converter.

Sometimes people want to run their softsynths through hardware (preamps, compressors, outboard digital stuff etc).

Also for doing a stereo recording where you are using a combination of software synths and hardware synths in Sonar.

I once had this offset problem (because Echo recommended using ASIO over WDM in Sonar). I definitely think more should be done about these issues. I guess the good thing is, it keeps me from wanting to spend my money on trying out other sound cards fearing I might have an offset problem.

And I don't think manually sliding every track you just recorded in place would be a good example of Sonar's great workflow. I can see if someone was trying to create an effect or correct a sloppy performance but for general recording that is not acceptable.

It sounds like you want a perfect solution though. I would think if they could just get the offset to a minimal point (under 3ms), most people would be fine and there would definitely be less complaining.

I think this problem also hits people who do a mixture of midi and live the hardest. I ran into this problem when a guitarist (who's been playing since he was little and had good timing) couldn't lay down his part properly to my sequence. He got really frustrated, but I knew what the problem was.

RE: Recording -- NOT monitoring -- latency (TwentyTimesSeven)

Tue, 07 Mar 2006 19:54:04 GMT

ORIGINAL: jt

ORIGINAL: TwentyTimesSeven
I did the loopback test with S501PE, an Edirol UA1000 and WDM/KS selected. It appeared to experience a latency of just two (2) samples at 44.1Khz/24 bit.

TwentyTimesSeven, that's impressive! I don't know of anyone else achieving that low of a difference. Perhaps someone else that has the same unit can perform a loopback test to confirm your findings.

I would like that. Not having done the test before I'd assumed that I was doing the test wrong. I switched to the ASIO drivers and got a much higher result (IIRC ~8ms). I'd be glad to do the test again and provide screen shots of my settings if anyone is interested.

20x7

ps: The above word is A S S umed.

RE: Recording -- NOT monitoring -- latency (jt)

Tue, 07 Mar 2006 19:10:03 GMT

ORIGINAL: TwentyTimesSeven
I did the loopback test with S501PE, an Edirol UA1000 and WDM/KS selected. It appeared to experience a latency of just two (2) samples at 44.1Khz/24 bit.

TwentyTimesSeven, that's impressive! I don't know of anyone else achieving that low of a difference. Perhaps someone else that has the same unit can perform a loopback test to confirm your findings.

RE: Recording -- NOT monitoring -- latency (Mr. G)

Tue, 07 Mar 2006 15:30:45 GMT

ORIGINAL: TwentyTimesSeven
With Kernel Streaming (WDM/KS) and a quality sound card and S501PE is this even an issue?

I must admit that I haven't tried a loopback test with Sonar 5.0.1 yet but when I tried it in 4.0.4 with my current USB-audio interface (BCA2000), the delay was about 9ms, which is not exactly negligable. This was with ASIO drivers - interestingly, WDM/KS was worse.

@Jean-Pierre: Seeing you have reported varying results, finding a universal solution may not be as easy as I thought it might be. Sorry to hear that.

For those of us who experience a constant delay, though, a quick fix according to what I suggested earlier, would be very welcome.

Jan

RE: Recording -- NOT monitoring -- latency (Sean*O)

Mon, 06 Mar 2006 19:10:57 GMT

I know exactly what you are talking about, and it drives me crazy! I do a lot of recording where I will overdub something like 70+ tracks of guitars, and these are all layed down one after another.

It drives me up the wall knowing that I played a track tight as can be, only to replay it and hear the whole thing off by quite a bit. I really don't like having to manually slide each track into allignment after every single take to see if it is going to work in the mix or not, but that is the only way that it can be done so far as I have found. Cakewalk really need to address this issue right away.

I was not aware Cubase had a feature built in to address this, but I will be looking into that option. It would literally save me hours upon hours of time, not to mention it would be so much less confining from a creative flow standpoint. Except from what I remember of Cubase, I hate it. PLEASE, Cakewalk, fix this problem right away and make another batch of lunatics happy again.

-Sean

RE: Recording -- NOT monitoring -- latency (TwentyTimesSeven)

Wed, 22 Feb 2006 20:19:20 GMT

With Kernel Streaming (WDM/KS) and a quality sound card and S501PE is this even an issue?

I did the loopback test with S501PE, an Edirol UA1000 and WDM/KS selected. It appeared to experience a latency of just two (2) samples at 44.1Khz/24 bit.

20x7

RE: Recording -- NOT monitoring -- latency (drummhedd)

Wed, 22 Feb 2006 20:10:58 GMT

I have been reading this thread and trying some different things on my system as well as checking some of my projects where there were tracks recorded after the rythym section was laid down. If I do the D/A A/D, there is a latency there, I didn't take the time to benchmark it, I knew that it was there already when I ran some tracks out through an outboard compressor and back in. But doesn't doing that actually double any latency inherent in your system? When I check my projects where guitar was added later, I cannot find any latency when I zoom in on the original say the bass and the added guitar, they line up perfectly. Maybe I'm just lucky or the guitar player had a 5 ms anticipation I don't know. I'm running S5PE with a motu 24i and have the mixing latency maxxed out to the fastest.

RE: Recording -- NOT monitoring -- latency (jppineau)

Wed, 22 Feb 2006 13:38:42 GMT

Hello Jan !

No Hammer at home ? (Jan Hammer...)

Well... the routine you are suggesting seems to be the obvious solution or inspiration for a solution. This said, my own measurements evidenced a fact that could be problematic... Some users claim to have a predictable amount of samples to offset (366 for some Motu users...) Those are happy guys (and gals), indeed.

In the few threads I've been in for that matter, the results were inconsistants, to say the least. My own results may vary impressively for the same tests (the loopback test), depending of... I don't know. I've been in the computer music since the Apple ll... I remember that the Roland U and D synths lines were doomed with 25ms of delay from the keyboard triggerring and the effective audio output rendition. In sequencer playback situations, these machines could not produce an 8 notes chords vertically. It was always a very fast succession of notes, one after one.

That was the state of the art at this time.

For example :
The setup at the studio make use of my 4 Adats as the converters. Thus, no AD/DA process occurs inside the computer. Do you agree ? Everything is routed to the DAW via Lightpipes (at lightspeed...) to a Dakota/Montana pair of cards where no audio is processed : only bits of digital data. So, I am dubious about the AD/DA lag controversy as the ADATS themselves are immune to this behavior. My guess is more that the PROGRAM has to make an interpretation of the data and to timestamp it's audio. That is this process that could be more robust. Also, I have migrated from Win98 to Win XP at the end of 2004... No WDM, etc under Win98se... but no delay ? I just noticed this behavior in SONAR 2 once I had ported everything under Win XP. Never before have I suspected this behavior and I work with these machines 7 days a week. This has been consistently repeated for other Sonar incarnations since then.

I must also add that I have a very long experience in beta testing for software companies... and that I have been implied heavily into the AcXel Resynthesizer development and... failure, from 1988 to 1992. I've seen limitations in all these areas. These were not bugs but physical limits induced by technology.

Finally, you are right about the fanatics of bit depht and sampling frequencies... As a record producer, no one has ever refused to play or buy my products based on the fact that it was recorded in 16 or 24 bits at whatever sampling frequencies... but many computer musicians seem to be ignorant of that basically unbearable musical constraint : the inherent lagging of DAWS.

Wild...

Jean-Pierre Pineau
QuÃ©bec Canada

RE: Recording -- NOT monitoring -- latency (Mr. G)

Wed, 22 Feb 2006 12:39:09 GMT

ORIGINAL: paulfurze
I know know why our brass players seemed to be 'lagging' behind when we recorded them.
In the monitors (hard routed via a desk) they sounded fine. But when listening to the recording they just seemed to loose that edge.

True, this seems to be particularly noticeably with brass. I had the same problem recently when recording our band's brass section, always wondering why they were lagging behind until I remembered this thread.

What really gets me is that people are discussing comparatively esoteric details (such as the question whether 64 bits sound better than 32), but when it comes to musically relevant issues - and in some styles the difference we're talking about can have a noticeable effect - hardly anybody seems to care.

ORIGINAL: jppineau
I suppose that we have reached the limits of this process for the moment. When some has to rely on turnarounds to pass over an issue THIS BIG, and that companies cannot address the problem, this is because we have reached the technical limits of current technology.

The funny thing about this problem is that it doesn't seem that difficult to solve. What I think should work is:

1) Create a function for establishing what the delay on a particular machine running a certain configuration is, i.e. some kind of Wave-Profiler for external gear. This could be done by:

- having the user create an out-in loop,
- playing back a track containing only one very short and distinctive signal (a snare hit or even just a short beep),
- recording this signal again through the loop,
- lining up the short signal of the recording with the original track (automatically or manually) and
- taking the amount that the recorded signal needs to be moved by as the resulting delay.

2) Sonar would now have to move every newly recorded track to the left by the delay previously established (and cut off empty bits at the beginning of the track if necessary). Problem solved.

I'm not a programmer, so it's easy for me to talk, but compared to many of the complex functions that Sonar has by now, this looks relatively trivial to me. Hopefully the good folks at Cakewalk see it this way, too.

Regards

Jan

RE: Recording -- NOT monitoring -- latency (jppineau)

Wed, 22 Feb 2006 11:57:26 GMT

Well,

I am among the people who complained about this state of fact. As I began recording in 1981 (on analog machines needless to say), I saw the arrival of digital audio recording ( since the ADATs) as the end of big corporate studios supremacy and a democratization of the studio creative process... I made my musical and artistic living out of the big cities, enjoying raising my family in a peacefull environnment (I am not a new-ager... don't worry !).

This problem just started to be really frustrating since Sonar... All ryhtmic figures, polyrythms etc. were hopelessly trashed in a sea of imprecision randomly generated. I had to compensate by ear, most of the time. Believe me : it comes to a point where you don't know what to trust and the feel of the moment can be perceived as wrong the next time you listen to the same project...

As I cannot see any solution in the DAW realm for the moment, I remain surprised to hear NO LAG when I make use of my old ADAT 32 track system... They make use of AD/DA conversion as well, you know ? Not very different of the card based systems many of us are using... I am dealing with the idea of getting back to hardware recording system with some basic Ã©diting capabilities... and then... make use of the DAW for finishing... That would be more reliable on long term projects.

The daw-only usage would be restricted to short productions like Jingles etc...

I suppose that we have reached the limits of this process for the moment. When some has to rely on turnarounds to pass over an issue THIS BIG, and that companies cannot address the problem, this is because we have reached the technical limits of current technology.

My two cents, anyway.

RE: Recording -- NOT monitoring -- latency (paulfurze)

Wed, 22 Feb 2006 08:47:42 GMT

Just stumbled accross this thread.

I know know why our brass players seemed to be 'lagging' behind when we recorded them.
In the monitors (hard routed via a desk) they sounded fine. But when listening to the recording they just seemed to loose that edge.
I evenvetually had to move phrases left to get them to sound correct.
Never considered that they were being recorded late.
I'll be testing this for sure tonight.

RE: Recording -- NOT monitoring -- latency (davidchristopher)

Fri, 14 Oct 2005 02:06:10 GMT

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

10ms is noticable if input monitoring is enabled. It's percieved as a lack of responsiveness, or even by some a touch late. And, on his system, each consequitive track is coming in 300 samples later. That becomes a big deal if you're laying down many tracks sequentially.

Is this input latency, or is output latency though?

Let's not start saying that 640kb is enough for anybody now... some of us have a valid need for low latency and accurate clocks.

RE: Recording -- NOT monitoring -- latency (jppineau)

Fri, 14 Oct 2005 01:59:44 GMT

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

RE: Recording -- NOT monitoring -- latency (gullfo)

Sun, 21 Aug 2005 21:57:59 GMT

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

RE: Recording -- NOT monitoring -- latency (Patrice Brousseau)

Sun, 21 Aug 2005 13:57:45 GMT

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

RE: Recording -- NOT monitoring -- latency (xackley)

Sun, 21 Aug 2005 10:12:23 GMT

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.

RE: Recording -- NOT monitoring -- latency (theblue1)

Sun, 21 Aug 2005 01:16:49 GMT

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

RE: Recording -- NOT monitoring -- latency (theblue1)

Mon, 15 Aug 2005 12:25:34 GMT

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!

RE: Recording -- NOT monitoring -- latency (RTGraham)

Mon, 15 Aug 2005 08:04:50 GMT

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!

RE: Recording -- NOT monitoring -- latency (mildew)

Mon, 15 Aug 2005 06:55:22 GMT

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

RE: Recording -- NOT monitoring -- latency (theblue1)

Fri, 12 Aug 2005 02:16:52 GMT

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

RE: Recording -- NOT monitoring -- latency (Mr. G)

Thu, 11 Aug 2005 03:09:05 GMT

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.

RE: Recording -- NOT monitoring -- latency (Mr. G)

Thu, 11 Aug 2005 01:50:01 GMT

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?

RE: Recording -- NOT monitoring -- latency (LoopJunkie)

Wed, 10 Aug 2005 18:51:53 GMT

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

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. Unless you have some super-duper-ultramega-excellent and impossible-to-emulate outboard gear on every track (while tracking??!!) this whole scenario doesn't make very much sense to me.