I've been reviewing this forum to find a way to record in sync while multi-tracking and cannot find anything that works.  No matter what settings I've tried, there is always half the "Reported ASIO Latency" at the start of the recorded file.  The Recording Latency Manual Adjustment appears to do nothing. Activating/deactivating the "Use ASIO Reported Latency" does not effect the offset either.
 
Some information:  48kHz-24 bit, Win7 64-bit, Sonar X3d, 4131 round trip latency, 42.7 ms effective latency.
 
Yes this is a large buffer, but lowering the ASIO buffers still has a recording offset (just smaller).
 
At the above setting, there is always 2143 samples of silence at the start of the file.  I've tried entering -2143 into the manual offset but nothing happens.
 
What have I missed?

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. 

So the recorded file will always have the ASIO latency of 2143 samples at the start with my example of a 2048 ASIO buffer size?  That would explain why everything I've checked and entered in Sonar is not doing anything to the actual recorded file.
 
What's upsetting me is opening the recorded file in a wave editor (SoundForge) and seeing the offset.  Then, when I edit the files or replicate, there are issues.
 
I don't like it, but it makes perfect sense in my situation.  After recording an audio click track with the ASIO latency enabled, the recorded track was lagging by 61 samples.  The manual offset was adjusted to +61 and all the waves line up in the track view.  However, the actual file itself still has 2143 samples of delay at the start before the first ping.
 
I'm going to have to give this some thought with regards to importing and looping.  What started all this was reamping a Kemper.  I'll post again when it sinks in...

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

I think you could back up a bit and review what might be causing your latency with a lower ASIO Buffer Size, as this is way high for tracking on your system.
 
My settings (check bottom of this post in my signature), give me no dropouts and no problems staying in sync either.
 
1.  What kinds of plugins are loaded into this project?  Be aware that some plugins are meant for mixing/mastering and NOT for tracking.  Such plugins would be those that use look-ahead processing or are otherwise very CPU-hungry.  (Boost 11 is one such critter).  Please list all plugins for the project in question, or if there are multiple projects, pick one with the issues and list all plugins.
 
2.  Do you monitor directly or do you monitor through Cakewalk?  
 
3.  Do you have a Wi-Fi adapter?  These can cause lots of latency issues.  It is best to temporarily turn them off or disable them just prior to running Sonar, then turn them back on or re-enable them after you are done with your Sonar session.
 
4.  For a test, if you don't mind, I would like you to set your settings to match mine below, then load up one of these problem projects and hit the letter 'E'  on your computer keyboard, which will toggle on/off Bypass All Effects.  If the latency issues go away, then one or more of your loaded plugins is causing the latency problems and should be swapped out or removed until you finish with tracking.  (You can load the plugin or plugins back in when starting the mixing/mastering process and raise your ASIO Buffer size at that point to allow for the extra latency generated by those plugins).  Also, hitting 'E' again will turn your effects back on.
 
Some plugins use look-ahead processing or lots of CPU, and can cause massive latency problems.  These kinds of plugins are not meant to be used in recording, and are meant to be used when mixing/mastering.  (Boost 11, LP53, etc.)
 
Bob Bone
 

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.
 
 
 

Right-click the clip and choose Bounce to Clip(s). This will write a copy of the file with the compensation destructively applied, just like export, and the clip will reference the new file. The original file will be orphaned (no longer referenced by the project) after saving and closing the project, but will continue to exist until you use Clean Audio Folder or CWAF tool.
 
 

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?

Good catch. I just did a quick comparison between X3e and X2a, and it appears they resolved the punch-loop recording issue, at least in part, by destructively applying latency compensation to punched recordings. Normal non-punched recordings still have the latency built into the file. But in X2a (and presumable X3d as well), both punched and non-punched recordings left the latency in the file.
 
But at the same time, it appears they're now writing an extra buffer of audio on the end of the file when punch recording. My guess is this was necessary to fully solve the issue with compensation when looping with punch-enabled without leaving gaps, but the logic gets a little tricky; I'd have to think about it some more when my brain isn't already hurting from a long day at work. 
 
Anyway, the solution is still the same: Bounce or export the audio to get a file that is truncated to the clip boundaries displayed in SONAR.
 
Another factoid: As you noted, the number of extra samples on the end of the file when punch-recording is not a full buffer. I'm finding that the the sum of this value and the compensation is exactly 2x the ASIO buffer size. So it would appear that they're capturing an extra buffer on both ends to give wiggle room to apply compensation (always more than one full buffer due to A/D conversion time and interface bus latencies), without having the file fall short of filling the punch region.

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.