Dan_E10
I guess that makes sense as the round trip latency on the outboard synth increases at double the rate of the softsynths if I'm understanding it correctly.  Double the ASIO buffer results in double the latency for softsynths, but 4x the latency for monitored signals.

Actually the factor is a little less than 2x for both because there's a fixed component of both input and output latency that doesn't change. And the discrepancy only increases by the absolute change in buffer size.
 
For example, at a buffer of 4ms, your round trip is about 10ms with 2ms for A/D/A conversion and PCI bus latency, and half of that, 5ms, is output latency to which soft synths are subject.  If you double your buffer to 8ms, your RTL goes to 8+8+2= 18, and outbound is 9ms. So soft synth latency is up by 9/5 = 1.8x, and RTL is up by 18/10 = 1.8x. But the change in the discrepancy is just the change in the buffer size, 8-4 = 4ms; the discrepancy (not including MIDI) was 10-5 = 5, and is now 18-9 = 5+4 = 9ms.
 
In any case, I agree that the really heinous error you reported initially would have had to be due to PDC. The garden-variety discrepancy you've measured shouldn't be a problem at lower buffer sizes where you need to be for the tracking phase of a project, anyway. And with an apparent MIDI transmission/response delay of only 4ms, even at that 8ms buffer size, a discrepancy of 9+4 = 13ms shouldn't be a problem while tracking, and will be mostly corrected by record latency compensation when you finally record the outboard synth.
 
Clear as mud? 

Haha, thanks for the correction brundlefly.  Yes that makes sense, I wasn't thinking it through clearly.  What I probably should have written is just that the discrepancy increases as the buffer increases.  Before getting into this problem, I was assuming that increasing the ASIO buffer would just delay everything together.  It took me be surprise when I increased the buffer to eliminate some clicks and pops from soft synths and then the hardware synth was not in sync with the rest of the project.  This makes me wonder if there's a better way to compensate this.  It seems like something like an "outboard synth" instrument track with automatic round trip delay compensation might be nice feature to have to avoid having to manually measure and adjust the Time+ field for midi tracks associated with outboard instruments.  I guess record latency compensation does this pretty well, but it would be nice to have on the playback side for cases where you aren't ready to bounce tracks yet and can't use a small ASIO buffer.
Dan

 
I've often thought it would be nice to have per-input latency compensation and a way to link MIDI tracks with audio track for external synths as is done for soft synths. I know some other DAWs do the latter and I even entered a formal feature request for the former to address the difference between digital and analog input latency. But it's never really been enough of an issue for me to really push for it. In fact, I rather like the "airyness" that results from having slightly different delays on layered hardware synths.
 
Ultimately, I prefer the KISS approach of just keeping the ASIO buffer as low as possible, and not worrying about any timing discrepancies that I can't readily hear with the "naked ear" (i.e. unassisted by zooming the timeline to see alignment errors), or that aren't unpleasant. And by the time PDC-inducing plugins are being added to the project, the synth audio should already have been recorded.
 
But if I really wanted to address it in a particular project, I think I would try routing all the ITB audio tracks to a "Compensation Delay" bus and adding an appropriately configured delay plugin (i.e. 100% wet) to the bus, rather than trying to compensate individual tracks one way or the other.

After some more testing with this it feels like two steps forward and one step back.  Working with an ASIO buffer of 14 ms to avoid pops and clicks from the softsynth end of things, I measured a delay of about 17 - 21 ms between the midi notes and the recorded track.  Using a midi grid of 960 ticks per quarter and a tempo of 120 bpm, I get a time+ value of about -33 to -40 ticks needed to line up the audio with the desired note on times.  However, using this time+ value does not get the outboard synth to completely line up with the softsynths during playback.  I need to use something closer to the total round trip delay to get things to sound like they're lined up.  Doing this makes playing the outboard synth live from the compensated midi track sound like the bounced track with record latency compensation turned on (and no time+ offset).
 
This makes me wonder if Sonar is doing some kind of delay compensation automatically on the soft synths even though I have PDC override on.  I would have thought I'd only need to compensate for the record and midi latency but not the playback latency as I thought that the softsynths would be subject to the playback latency as well.  If not, so be it as long as it's consistent.  I will have to play around with this some more unfortunately because after closing the project to work on some other projects, and then reopening it, sync between the outboard synth and the softsynths seems slightly off again.  The strange thing is that bouncing the track to audio with record latency compensation on seems to consistenly result in a track that lines up subjectively with the softsynths.  However live playback of the midi track while monitoring the outboard synth seems to give slightly different results each time.  After updating to the X3e patch, I found I could run lower latencies without clicks and pops so hopefully a lot of these headaches just go away.
Dan

Dan_E10
....and then reopening it, sync between the outboard synth and the softsynths seems slightly off again.  

What do you mean in terms of ms or samples - how much is it?
 
I made some experiments thinking now I should make this line up in a perfect way.
So I rendered external synths one time, and got one result, another time and got another result.
 
Then I came to think of that deviation was within the period length of the sound produced by the note I used as reference.
 
What was noise, and which little cruising on audio should be reference and line up?
 
A normal A - 440Hz - period length 2.3ms - 110 samples at 48k.
Is it 82 Hz, like open 6th string on guitar - 12ms - 576 samples.
Is it a bass note an octave down form that - 24ms - 1152 samples.
 
So what do I use as reference - the start of the waveform to align with grid?
And how do an external synth generate a note sound?
How long is attack time of that sounds ADSR - also matters when you actually see part of a waveform to align with the midi you see on grid?
So what is the delay of synth to respond - and what is part of patch you are playing?
A fade in of 10-15ms is common to work as non-pop sound to arrive.
 
The external synth has it's oscillators running(seems to on my Hammond anyway emulating free running tonewheels) - and a midi note arrives. It can be different which part of waveform you see first.
 
So trying to get sample accurate alignment might not be possible, and you have to adjust depending on synths and even patch used.
 
But you should use a fast attack patch to get overall propagation delay for synth to respond.

Hi lfm, thanks for the response.
 

lfmWhat do you mean in terms of ms or samples - how much is it?

 
I'm measuring in milliseconds and then converting to ticks to determine what value to use in the time+ field.
 

lfmI made some experiments thinking now I should make this line up in a perfect way.
So I rendered external synths one time, and got one result, another time and got another result.
..... 
 
The external synth has it's oscillators running(seems to on my Hammond anyway emulating free running tonewheels) - and a midi note arrives. It can be different which part of waveform you see first.
 
So trying to get sample accurate alignment might not be possible, and you have to adjust depending on synths and even patch used.
 
But you should use a fast attack patch to get overall propagation delay for synth to respond.

Yes, I agree sample accuracy is not possible in this case.  I'm just shooting for a tracking that sounds subjectively in groove with the softsynths.  For testing this, I'm using a patch with a fast attack, the attack stage is set to minimum on the outboard synth, and a midi note somewhere around middle C.  I realize there will be some variability when zooming in on the audio and midi tracks due to things like free running oscillators being in different spots at each note on.  However, the inconsistency I'm experiencing here is larger than that.  I'm actually hearing the track from the outboard synth sound slightly out of sync from the softsynths when played live and monitored through Sonar.  This implies to me that it's more than a variability of a few msec.  The weird thing is that every time I bounce the track using record latency compensation, I get something that sounds completely in sync with my softsynths.  So it seems that Sonar is correctly using the reported ASIO latency to arrive at the bounced track.
 
For some reason there seems to be some variability in the latency of the live monitored tracks during playback that is preventing me from using the time+ field to consistently remove it.  As I stated above, I can set time+ to a value that makes the outboard synth subjectively sound in sync with the soft synths.  Then later, after reopening the project the outboard synth no longer sounds in sync and I need to find some new value to use in time+ to get it to sound right.  It looks like that last test I need to do is measure latency at the beginning of a session and then later at the end of the session to see if it's really changing all that much.
Dan

Dan_E10
Working with an ASIO buffer of 14 ms to avoid pops and clicks from the softsynth end of things, I measured a delay of about 17 - 21 ms between the midi notes and the recorded track.

First, I think you need to find a way to get your ASIO buffer down without getting pops and clicks. Your 1820m should be able to take just about anything you can throw at it with a buffer of no more than 6-8ms. Unless your projects are extremely plugin-heavy, you shouldn't be having to run a buffer much higher than that. And if you can't run a basic project with a few soft synths and FX in it at 2ms, you should start by downloading a free DPC Latency checker like DPCLAT or LatencyMon (Google them) and making sure you don't have high or variable/spiking DPC latency. 
 
Trying to compensate MIDI-Audio delays starting with a large ASIO buffer is bound to be a losing proposition, especially when using per-track time offsets in ticks that vary with tempo.
 
As I said earlier, the best solution is just to get all the latencies down to a point that it's not bothersome and doesn't need to be corrected. You should be able to do that with anything resembling current PC hardware, although the fact that you're running a PCI-bus interface suggests your PC might not be state of the art (since most current mobos don't have PCI slots). What are your PC specs?

Hi brundlefly,
Thanks for the response.

brundleflyFirst, I think you need to find a way to get your ASIO buffer down without getting pops and clicks. Your 1820m should be able to take just about anything you can throw at it with a buffer of no more than 6-8ms.

8 msec was the value I set my 1820m's buffer to for the last few years.  I've only recently started increasing it to 14 msec after upgrading to X3.  It seemed X3 was heavier on the CPU in my case and required a larger buffer to avoid clicks/pops.  Since I was running mainly midi tracks entered straight from either PRV, staff view, or step sequencer I figured low latency wasn't really a necessity.  After wrestling with these sync issues, I can see that low latency would simplify things even when not playing synths live from a keyboard.  After updating to X3e, I wasn't getting clicks and pops at 8 msec buffer so it looks like that may have been resolved.  I'm keeping my fingers crossed on this, because my click/pop issues in X3 seem to go away temporarily whenever I reinstall drivers and then come back after a few days.  Hopefully the X3e update has fixed this for good.
 

brundleflyTrying to compensate MIDI-Audio delays starting with a large ASIO buffer is bound to be a losing proposition, especially when using per-track time offsets in ticks that vary with tempo.
 
As I said earlier, the best solution is just to get all the latencies down to a point that it's not bothersome and doesn't need to be corrected. You should be able to do that with anything resembling current PC hardware, although the fact that you're running a PCI-bus interface suggests your PC might not be state of the art (since most current mobos don't have PCI slots). What are your PC specs?

I built my computer in 2011.  As I remember PCI slots were getting scarce even back then and I had to narrow down my motherboard search to find one that had them to keep using my 1820M.
 
My PC specs are:
Win7 64 bit
Intel I5 2500
4 Gb ram
Asrock motherboard P67 Extreme 4
 
Dan

Definitely check your Deferred Procedure Call (DPC) latency - not to be confused with audio latency. This is measure of your CPU's responsiveness to requests to service the ASIO buffers; if it's too slow or highly variable, you get dropped buffers that cause the pops and clicks.
 
I had already retired the 1820m sometime before X2/X3, but based on my experience running it under everything from S6 to X1, I'd be very surprised if its performance were affected significantly by a change in the version of SONAR alone, though X3 did see some changes to the audio engine - mainly around the "Always Stream Audio Through FX" functionality vs. the old "Play FX Tails" option.

I'll check the latency as you recommend and see if it looks like it's spiking.  I had looked at the "Always Stream Audio Through FX" settings as some others on this forum reported getting dropouts after upgrading to X3 from X2.  Unfortunately, it didn't have an effect in my situation.
Dan