Manual vs Audio Driver Latency Offset

Reading about testing round trip latency to determine how accurate the audio driver is reporting.  Seems as simple as recording or loading a simple audio clip, then routing the output of the interface to an input of the interface and record to a new track and observe the delay in samples.  
 
Ok, I can do that...but doesn't the latency change as a project evolves, adding and removing tracks, muting and playing back multiple tracks, recording 10 or more tracks at once..and etc.?  I don't see how I can enter a static number for latency offset while latency remains dynamic.
 
I like the idea of testing and making latency calculations more precise, but I thought the audio driver was continuously handling the dynamics of latency as the project evolves.  Am I way off on this?  

The audio driver attempts to operate with the latency you set. If the project demands more from the computer than the computer can provide as regards preventing the buffer from emptying you get crackles, drop-outs etc. Until you are asking more of the computer than it can handle adding audio tracks won’t make much if any difference. Sonar, like other DAWs, does not handle the buffer setting “dynamically”, it simply attempts to pass data through the driver.

Plugins can add latency if they need more time to do their thing than the buffer and computer can handle. Some plugins have a fixed amount of latency which sometimes can be quite high (in a few cases as high as a second or more). Sonar, like pretty much every DAW, compensates for the time required by extending the latency time to take account of them.

The manual latency offset is there to deal with the situation that the ASIO driver doesn’t report the latency correctly to Sonar or the interface/driver places audio in not quite the right time-slot for some reason. The latency isn’t reported correctly by some interfaces because they contain a “hidden” safety buffer with a fixed value in time/samples, which can sometimes be quite significant. If that field needs an entry in it a single fixed amount will usually work for all buffer settings.

Given how easy the the fix is, I don't see why one would be satisfied with an incorrect latency value. This is even more important when using multiple interfaces as some under-report and some over-report latency. I would imagine over time, all of us use more than one interface and having the correct latency setting insures the clips are lined up correctly regardless of the interface used.

I would think 1.8 ms is well below the threshold of what we should be worrying about. I start to hear latency at around 7ms. I guess it comes down to wanting music that is perfect, I would think perfect music would belong in an elevator :) 

Cactus Music
I would think 1.8 ms is well below the threshold of what we should be worrying about. I start to hear latency at around 7ms. I guess it comes down to wanting music that is perfect, I would think perfect music would belong in an elevator :) 

Well, I can't speak for others, but in my case it's not about music being perfect or I would just record MIDI notes from an electronic kit and quantize.  Instead, it's this weird sensation of the sound of my drums slightly behind the feel of them.  I worked through several songs like this and I could never quite accept the delay between hitting and hearing.  It's not that noticeable, but it's just enough to never feel "on" and in the pocket when listening through the isolation cans.  Electronic drums felt the same way.   

scook
You have changed the subject from recording audio to recording MIDI. The manual offset affects the location of recorded audio on the timeline.
 
When using an ASIO driver the offset is intended to correct the reported driver latency. As I mentioned above some drivers over-report and some under-report latency. My current interface over-reports latency by 21 samples. My last interface under-reported by 76 samples.
 
I suppose the setting could be used any way you wish but I have never heard of anyone using it to address the distance between a listener and the monitors. Not sure that is a good idea.
 
FWIW, here are a couple of threads about the setting
http://forum.cakewalk.com/FindPost/1301345
http://forum.cakewalk.com/FindPost/3178396
 

Yeah, I won't be setting mine to deal with the distance between a listener and the monitors.  I did think it was pretty interesting that he went that far with it, and seemed to understand what he's doing.  Mostly I'm about getting the drum tracks locked in and they will always be tracked with my isolation cans on.  
 
Here's the link to the thread if you are interested:  https://forum.cockos.com/showthread.php?t=48884

Yes midi delay is a whole other kettle of fish. The solution to your problem is always direct monitor the Drum Brain while tracking. It's easy to find out is there is latency, just toggle the VST drum Input echo as you play. You'll hear the digital delay. I agree even a tiny bit is annoying with drums. Never had a issue with keyboard.  
So I keep my kit patched into my monitor mixer and keep input echo off on AD2. 
 
Back on topic. 
 

• Milliseconds X the sample rate = # of samples In the example, if the delay between a pair of room microphones and a soundboard feed in the record's home studio is 17 milliseconds of delay (based 17 feet of distance), the formula becomes:17 times 44.1 = 749.7 samples.  

In this case, the recorder enters a sample delay of 749.70 samples into the software for the closest source to time-align the sources.

• Samples divided by ​the sample rate = milliseconds   
• so if a loopback test track is out by 44 samples it is about 1 ms not really noticeable, but a track out by 440 ms is 10 ms so would be very noticeable.  This is why the loopback test is important and even if you don't find anything out of sorts I think it's important to understand your system and how it's performing. In my case both my interfaces were only out by under 10 ms so there was not great need to adjust the timing manually.