Note added May 15 2016- Sorry my pictures seem to have gone offline So original I stored in Photobucket is gone... I'll just put a new one I made here for now, but it is not the same so my text might not be correct.
. 

 
This sort of started with another thread where a us1800 owner was not happy about his tracks being around 2,000 samples out of alignment.  I started doing some loop back test of my own. I now believe everyone owes it to them selves to run this test and see if your audio interface drivers are telling the truth to Sonar. 
What I'd like is for different people to post a screen shot of the same test. Maybe we can learn something, maybe this is pointless sound nerd stuff. 
 
Drivers work with Sonar to adjust playback latency so your new audio tracks are perfectly in sync with the original tracks used for playback. It's called offset.  Therefore monitoring at your interface will result in all new tracks lining up as long as you play your part with tight timing. If this sync if off by say 10 - 40 ms you'll be scratching your head and start thinking you suck. I'm good now thanks to my Scarlett, but this was not always so in the past.. read on
 
The loop back test: 
Simply you patch the audio output back to an input and record any super transient track. You zoom way in and see if they are lining up. 
 
I used a midi drum track and froze session drummer. This will create an audio track that should line up to the sample with the midi track.  
Now insert a new audio track and make sure not to turn on input echo, better yet set it's output to "none". 
Select the track the input, I'm using my back panel line inputs therefore the level was at unity. - Arm the track and hit record.  I'm only looking at the starting offset. You are welcome to see what happens after 3 minutes too. 
I'm using 44.1 / 24 bit 
It's hard to read the track titles but the from top to bottom is the midi track, the frozen synth then the looped back tracks using different driver modes if available. 
I first tested my Tascam us1641 on behalf of the us1800 user to see if I got similar results. I tested with the normal buffer setting and then the highest buffer setting. Both were the same being around 400 samples early.
I then tested WDM mode( bottom track) and it was 800 samples late. MME mode wouldn't let me loop back. 

 
I then tested my Scarlett 6i6 and was please to find it was really really right on the money. I tried different buffers as well but that seems to make no difference. It would not run in WDM mode, fine by me. I even zoomed in way closer and could not see any offset. So which interface are you going to use? Right. 

So now I'm real curious about this and fired up my office PC which has this circa 2003 Card Deluxe PCI audio card. My son said it was used in a radio station. Turns out it's better than I realized. I never got into it because like most PCI cards it's bare bones 2x2 1/4" TRS and SPDIF.   They even had W 7 -64 driver for it.  I got the same results in both ASIO and WDM mode. It wouldn't do the loop back in MME either. 

Last but not the least is this cheapo Berhinger USB box that came with the mixer. It has 2x2 RCA. 
I'm using it just fine for live performance playback. It's plug and play and actually works great. Great as long as you don't mind using MME mode with Sonar. I tried ASIO and WDM and it said no can do. 
But as you see it also is late by 400 samples. 

 

 
Johnny, could you please explain to me how a loopback can arrive earlier than the source ?
 
I must be missing something in the picture.
 

If the offset used by RLA is larger than reality, the result will be shifted further back in time than it should be.  Accurate measurement requires that RLA be zero during the test.  To do this, uncheck 'Use ASIO Reported Latency' and make sure 'Manual Offset' is '0'.
 
This will let you determine the actual RTL for comparison with what ASIO reports.

 
From the help Files: 
If you use ASIO mode, enter 0 in the Manual offset field and leave the Reported Input Latency check box checked (this check box only appears in ASIO mode). This will line up audio in most cases. If you think you can tweak it closer, use the Manual offset field.
In ASIO mode, the current active ASIO device (remember ASIO can only have one active at a time) reports its "Input Latency." You can't edit this value. This supposedly accounts for buffer size, A/D Conversion latency, etc. The check box allows you to use this reported value. It is checked by default. In any case, the amount entered into the Manual offset field will be combined (added to) the reported value if you have it checked.
 

 
This will be the default and unless your drivers are screwball you shouldn't have to ever think about it. This is the point of this thread. Sure I could take the Tascam and do the math and make it line up... but to me that's garbage. I bet everyone with a "good" audio interface will find the results are like my Card Deluxe or the Scarlett. This is why I'd like other people to run the test. 
 
Paul this is the best I can do, because I really can't find solid information about this. If any of this is wrong that  please people's chime in to correct mistakes.
The latency is calculated and the DAW's output has to be sent out ahead of time to compensate for the input latency of the A/D and USB or firewire etc. Latency is added at each processing step so the audio driver is supposed to calculate what it will take to make the new input line up with the already recorded tracks. 
From what I understand... the signal from your DAW you hear in your headphones is being played at the calculated output latency. It has pushed the audio ahead to make up for the latency of it getting to your playback system via the USB system and the D/A convertor of your interface,
 
Then it also adds in the latency of the return trip of the overdub input signal. 
So as in above example, RTL of 1312 samples ahead of the now time marker lines everything up nicely. 
Obviously the Card Deluxe (and Focusrite) drivers got this right, and Tascam didn't. 
The Tascam reported latency was ahead by 400 samples in ASIO mode and Behind 800 samples in WDM. 
This is also insight to me on why we need to be using ASIO mode don't you think? 

It really needs to work perfectly. 
At 44.1  approx 88 samples is a millisecond. Phase issues and what is called the Haas effect
http://en.wikipedia.org/wiki/Precedence_effect
 
can happen at even around a 2 ms offset. This is all nit picky but the point of this thread is to learn more about this. Please take the time to do a loop back and post a screen shot. The more the merrier. 
 

Zeroing RLA they way I described is for measurement/verification.  Not the way to run for production.
 

 
Thanks Cactus and BobF.  There's more going on than I realized.  I will definitely be measuring my own cheap interface the minute I get the time, which won't be right away unfortunately.  Maybe this evening.
 

 
I just tried this out with my Mackie Blackjack.
 
Reported ASIO latency is 864 samples.  To line things up as close as I could, I had to set the offset to 698 (Use reported latency unchecked).
 
For some reason, I'm not able to achieve a perfect match but am either ~3-4 samples early or late by changing the offset amount by 1 sample.  So an offset amount of 1 sample moves the track audio by ~6-8 samples.
 
So it looks like my interface/driver's reported latency is off by 166 samples.

Thanks Paul this is what we are trying to figure out. 
 Mackie is like Tascam, excellent hardware with iffy drivers. 
What I'd like more than anything is if someone could test the new Tascam interfaces. 
 

I have a 16X08 due to arrive tomorrow.  I'll have a mini review with some latency numbers in a few days as I get time

over 100 views and only 3  people?  Come on folks, don't be nervous. 
You don't have to post a screen shot, just tell us which interface your using and if it came out good or bad. 
I'm mostly targeting those iffy drivers of iffy cheapo interfaces. 
Part of this is education for those who don't believe us when we say you owe it to yourself to purchase a "good" audio interface. 
 
Way to much focus is on getting low RTL and not on overall stability. Just because your interface has low RTL doesn't mean squat if the clock is out of whack.