Recording Latency Manual Adjustment

Manual Offset is additional latency compensation, so you would want to enter that as a positive offset. And there should definitely be a difference between enabling and disabling Use ASIO Reported. Typically you would enable that and only have to add another 30-50 samples or so of Manual Offset to compensate for unreported A/D/A conversion time.
 
EDIT: I just noticed your mentioning there being silence "at the beginning of the file". Latency compensation is applied non-destructively to the clip representing the file in SONAR. The file itself will continue to have the latency in it until the clip is bounced or exported to create a new file. 

If you integrate your wave editor into SONAR (see link below) and select a section of the clip, you can launch the editor via the Utilities menu in SONAR and it should open with with the relevant section selected and zoomed in the editor - at least that's how it works with my ancient copy of CoolEdit2000. This should make it easier to keep track of where you are.
 
http://www.cakewalk.com/S...reader.aspx/2007013099

brundlefly
 The file itself will continue to have the latency in it until the clip is bounced or exported to create a new file. 

 
That is interesting.  Bounced and exported files are latency-free (no delay).
 
Now to answer Mr. Bone's questions:
 
1.  There are no plugins on this project.  There have been and their removal did not change anything.  This project is strictly a metronome wave file at 100 BPM at 48 kHz/24bit playing on one track and being captured on another through the converter via an analog loop.
 
2.  I play a guitar and/or sing to a cakewalk project.  All recording is normally punched in.  Hence, when I open a captured file in SoundForge, the initial latency is obvious.  I do not monitor through Cakewalk, I play with the project and capture.
 
3.  No Wi-Fi or any internet on the DAW.
 
4.  Setting up per your recommendations:
48/24, ASIO buffer at 128, 512 on I/O buffers, ASIO auto latency is active, total round trip latency = 6.1 ms, 291 samples
 
The actual latency (delay) at the start of the recorded file is 225 samples.  In the Sonar Track view, the recorded file was behind the metronome file by 61 samples.  So adding a manual offset of 61 samples lines up the recordings perfectly.
 
There is still a delay in the recorded file, but is is much smaller (as expected) with the smaller ASIO buffers.  What is giving me fits is I expect a 8 measures of common time of a 100 BPM recording at 48/24 to be 921,600 samples.
8 measures * 4 beats * 60 seconds / 100 BPM * 48,000 = 921,600 samples.
 
So when I punch in an 8 measure guitar track, it is not 921,600 samples, but something larger.  There is always this silence at the start of the file (the 225 samples from above example) and then some extra at the end, too.  These additional samples are stopping me from simply cleaning up a track and importing into another project for use.  To the the proper length, the initial silence and the end have to be trimmed to the 921,600 samples.
I guess what brought on this inquiry is my starting to reamp and realizing that the recorded files were not what I expected. For years I thought that Sonar handled recording latency during the RECORDING process and not during the PLAY process.
 
Is there any way to record the files with out the silence at the start AND have the proper length?  If not, I'll have to either fix every file with a wave editor or learn a new process/method.
 
 
 

What timing:  It would appear that the X3e update solved the problem (or 99% of the problem).
 
Running 48-24 with 2048 ASIO buffers and 512 I/O (same as last night).  Recorded the click track and the start of the first click was 2143 samples behind.  This was with 3Xd.
 
Updated to 3Xe (only change) and the next recording was 61 samples off.  So the 61 samples were added in the Manual Offset and now all is perfect.  The original click *.wav file lines up in the Console View AND each file lines up in a wave editor.  The manual offset and the ASIO latency do effect the recorded file.
 
The only issue now is the captured fill is still not the same length as it should be.  The file should be 921,600 samples (as calculated from sample rate and tempo), but it is 1440 samples too long.
 
Referring to the 3Xe update, below is a quote:
 
"Resolved an issue where recording between punch points could offset the audio recording by the current buffer setting."
 
That sounds like what was happening to me.  Now, I'm just wondering why the file is not the correct length?

Yes, "bounce to clip" does correct the length of the file.  However, if the user punches in and out on a certain measure with a given BPM and sample rate, the length of the recorded file is predetermined and that's what it should be, period.
 
But at least the more important file synchronization at the start has been corrected.