Hello everyone.
 
I've searched around for answers to this and while I've found a solution, I haven't found out why it's happening or what you can do about it.  I've been using Pro8.5 & it also appears in X1.  I've not tried X2 yet but judging from the link below, it still happens.  I can't try X3 as I'm not licenced for that just yet!
 
Basically, if I record/bounce MIDI to audio, be it internally from a VSTi or an externally recorded synth, when I play it back, the audio plays slightly ahead of any other MIDI instruments whether they are a VSTi or other external hardware synths!
 
Now, I've absolutely no latency problems with my soundcard or dropouts, etc, as all my MIDI VSTi's & external synths all play in time with each other so that's not it!
 
Also, all the MIDI data has been quantised and as I've said, that's not the problem as that all syncs up and sounds on beat so I know my interfaces are working fine.
 
What I've discovered is if I use the "Timing Offset" setting and specify a delay of about 40ms, everything plays in time without any drift either!  If I don't adjust this setting, ie, I leave it with no offset, then when playing back the recorded audio with the original MIDI file outputting to a VSTi or hardware synth, there's a fraction delay going on which is perceivable as you hear the recorded track fractionally before the MIDI sounds.
 
I hope this is making sense.
 
Does anyone have anything to add?  Have I missed something during the set-up phase?
 
Just for the record, I've run the wave profiler and my soundcard buffers are at 2 and audio latency settings are at about 11ms which I've lowered as I'm not getting any problems.
 
The solution to the problem is here: http://www.cakewalk.com/Documentation/default.aspx?Doc=SONAR%20X2&Lang=EN&Req=Dialogs2.056.html
 
I'd really like to know why this is happening and whether anything can be done about it.
 
Many thanks for any input.

RickJP909
Basically, if I record/bounce MIDI to audio, be it internally from a VSTi or an externally recorded synth, when I play it back, the audio plays slightly ahead of any other MIDI instruments whether they are a VSTi or other external hardware synths!

This needs to be verified/sorted first. VSTi output is buffered up in advance of playback, and handled much more like internal audio tracks than is audio from a MIDI-driven hardware synth. As a result, it won't be affected by the setting of a non-zero Timing Offset. The only case I know of where frozen/bounced soft synth audio timing will be noticably and consistently off is when using a 32-bit Bitbridged synth in which case an extra empty buffer of audio can be added to the rendered audio causing it to play late by the size of your ASIO buffer (I say "can", because I'm not sure it affects all soft synths; I originally noticed it with BFD Eco and Dropzone). This is an acknowledged bug with Bitbridge.
 
So I would suggest we try to get soft synths out of the equation first. Then, if recorded hardware synth output plays early relative to the same track playing live (and relative to the audio metronome), I would be inclined to suspect your record latency settings are overcompensating the audio after recording.
 
EDIT: You mentioned "profiling" your interface, which implies you're using WDM driver mode. The first thing I would suggest is that you switch to ASIO, which is generally preferred, and will give better control of latency compensation. Also, make sure you Record and Playback Timing Master selections are correct and referencing the same device (M-Audio Delta?).

There is a trial version of X3 available for those needing a version for testing.

brundlefly
This needs to be verified/sorted first. VSTi output is buffered up in advance of playback, and handled much more like internal audio tracks than is audio from a MIDI-driven hardware synth. As a result, it won't be affected by the setting of a non-zero Timing Offset. The only case I know of where frozen/bounced soft synth audio timing will be noticably and consistently off is when using a 32-bit Bitbridged synth in which case an extra empty buffer of audio can be added to the rendered audio causing it to play late by the size of your ASIO buffer (I say "can", because I'm not sure it affects all soft synths; I originally noticed it with BFD Eco and Dropzone). This is an acknowledged bug with Bitbridge.

 
Hi Brundlefly and thanks for replying.
 
You're correct in that statement and it was what I was desiring as I didn't want to modify the timing of my VSTi's as they're bang on time with all my hardware which is routed through a couple of Roland/Edirol interfaces which have always provided perfect sync with any other hardware I've used so I'm pretty certain it's not a problem there.
 
I'm also not using BitBridge as even though my Win7 is 64-bit, I've always installed the 32-bit versions of Sonar to avoid problems with plug-ins.
 

brundlefly
So I would suggest we try to get soft synths out of the equation first. Then, if recorded hardware synth output plays early relative to the same track playing live (and relative to the audio metronome), I would be inclined to suspect your record latency settings are overcompensating the audio after recording.
 
EDIT: You mentioned "profiling" your interface, which implies you're using WDM driver mode. The first thing I would suggest is that you switch to ASIO, which is generally preferred, and will give better control of latency compensation. Also, make sure you Record and Playback Timing Master selections are correct and referencing the same device (M-Audio Delta?).

During playing or recording of my VSTi's or hardware synths, Sonar's Audio Metronome is in perfect sync or should I say the soft and hardware synths sync perfectly with the Metronome.  If you mean the Record Latency settings in Advanced, the Manual Offset is set to 0 but in the Aud.Ini config file, I've noticed there is an entry which reads "LatencyMsec=15" and I'm not sure what that's for.
 
You are correct about me using WDM and I did wonder about using ASIO.  My Play and Rec Timing Master settings are both set to the same "Delta AP" options for M-Audio.
 
I'll try switching to ASIO to see what difference it makes but what'll happen to what's been recorded already as I've put down loads of audio tracks into my project now?

If it is a record latency compensation issue, existing recordings won't be affected by the change to ASIO. You'll need to do some testing with a new project or new recordings in an existing project to see if it makes any difference.
 
But if you have multiple interfaces using different drivers, you would have to stay with WDM to have access to both. If they use the same driver, I think you should be able to switch to ASIO and still have access to I/O on both interfaces, but I'm not sure about that.

Well, after some testing, it seems as though the cause was indeed the Mixing Latency Buffer Size setting which was originally set to around 30ms as a default.  Using ASIO also solved it as you suggested and it's that which gave me the clue as when I checked the AUD.INI file, the latency variable had been modified to a very low figure.
 
However, over time I'd been lowering this setting as I found when playing the keyboard on external synths there was a latency delay being caused by this so I lowered it.  What I didn't realise is that this setting affects the recording process!!!
 
Therefore, having lowered it to 5ms, everything now records in sync!  However, as I'd been changing this setting over the course of my project, I now appear to have different audio tracks recorded with different latencies - arrrrhhhhh!!!!
 
So, my last questions:
 
1.  What's the lowest latency setting you can have before you start getting problems?
2.  Are ASIO drivers really better than WDM as there seems to be quite a debate and it seems to depend on who you talk to as to what they recommend and the camp seems to be divided right down the middle on this topic?
3.  Any ideas on how I can get all my recorded audio to line up properly without having to re-record each track or spend silly amounts of time lining each one up?
 
I don't want to stretch or alter its timing as that's fine, I suspect it's just a case of getting each track started in sync as the actual MIDI sync is spot on as it doesn't drift.
 
Cheers for all your help.

I think you'll find that most manufacturers, including M-Audio, recommend using ASIO if the host supports it. An ASIo buffer of 128 samples is low enough not to be bothersome when recording hardware but high enough to accommodate most projects. If it's too low, you'll start to hear get pops and crackles on playback from dropped buffers.
 
Automatic latency compensation should have compensated for whatever latency was in effect at the time, whether using ASIO or WDM drivers, but if something was wrong and audio was not compensated properly in some projects, manually compensating those recordings as needed is really the only solution.

Hi Brundlefly and you are correct again as after posting my question, I did some digging around the M-Audio KB and found an article detailing how to set-up the Delta card with Sonar and it did indeed recommend using the ASIO drivers which I'm now doing.
 
It now reports that my card has a latency of about 6.5ms in the signal input which I gather anything below about 10ms is considered good.  However, having run the DPC Latency tool, that indicated that my system is capable of near instantaneous audio as it was reporting a latency of only around 100-200uS.
 
Do you know what latency your card produces?
 
So on that basis, if I wanted to further reduce my latency setting, is that what the Manual Offset Adjustment is in the settings area as shown in the link at the top of the page?  Is it possible to reduce that figure as I'm not getting any clicks or pops so far so why not reduce the latency as far as possible?  I understand that it places an overhead on the CPU but I have a 6-Core CPU and so far it doesn't even seem to be getting "out of bed"!
 
I'm also going to re-name this post so that it may be more useful when searching the forum for those who get similar problems with M-Audio PCI interfaces as the Delta range are popular cards.

DPC latency is a measure of how fast your CPU can respond to a streaming request from SONAR. Under 200 microseconds is reasonable, but not stellar - mine is in that same range. A lot depends on the quality of the interface and its drivers; the Delta's a pretty old card, so I'm not sure how well it handles very small buffers, but you can certainly try 64 or even 32 samples and see how it goes.
 
The Cori Yarckin and Javier Colon demos that came out with X2 and X3, respectively, make good performance benchmarks. With all synths and FX unfrozen, I have to run a 256-sample buffer on my old Quad Core to get smooth playback with either of those. I do pretty much everything else at 128, and can go to 64 in very light projects. Whatever buffer you are able to run those projects at, you can probably comfortably go to half that for everyday work, assuming your average project is not that complex, and maybe a quarter when you want the lowest possible latency for tracking.
 
As you say, lower is better if the machine can handle it, but at a certain point, your CPU will working hard enough even at idle that you'll just be wasting energy, generating a lot of heat, and causing your fans to make more noise.
 
Click the ASIO Panel button on the Driver Settings page to get access to the buffer setting, which is your main latency control. The Manual Offset is for entering a value to dial in your Record Latency Compensation in conjunction with the automatic compensation to get sample-accurate compensation of the clip position for the Input latency. This happens after recording is stopped, and doesn't affect the realtime latency. Download the free Centrance Latency checker to measure the actual round-trip latency and determine what the Manual Offset needs to be (Centrance measured value - SONAR reported value).