ORIGINAL: bbdude
I wish there was a way to make this correction on a per-input basis.

We asked for that way back when, but unfortunately, Ron Kuper left CW before it gathered any steam.

I agree 100%. But I would be satisfied with the correction being on a per device basis, since it's very rare that inputs of the same type would have different buffering. (Of course, things like ADAT and S/PDIF on the same unit would need their own settings distinct from analog i/o's, but I think you know what I mean.)

Interesting as usual Jim.

What you're saying about double-buffering totally explains why some interfaces appear to defeate time. I just learned that, with ASIO drivers, the Fireface reports the latency caused by the oversampling process of the converters as well as the Safety Buffer (Playback side only) latency to the system. I thought that was cool, but it also made me wonder, why do I still have to align audio with a loopback test in Sonar? Shouldn't that be automatic if the drivers are also reporting the extra inherent latency? This could either mean that Sonar is not handling this information properly (incomplete feature?) or that they decided to do it differently for some reason. It seems that Cubase and Nuendo handle this more efficiently from what I've read. It'd be interesting to know how Sonar handles this compared to them.

I like your "ping tool" idea. It would be like having CEntrance built into Sonar. But I would just settle for having separate manual offset boxes for each type of input (Analog, ADAT, SPIDIF). That would at least keep the analog and digital world in sync. Now that I think about it, this calls for a feature request....the more the better. Maybe if we insist enough Cakewalk (by Roland) will incorporate it for us in S8 .


Take care!


Edit: for clarity.

couldn't we test this by unchecking the asio reported latency box?

GotMetalBoy,

For some reason I'm not able to reproduce this on my system. First I went into Options::Global::General Tab to disable "On Stop, Rewind to Now Marker" since it is checked by default. Then, I inserted SD2, selected a program and used the Kick Drum sound as my pulse. Bounced to Track and played everything together, stopping several times by repeatedly pressing the space bar on my computer keyboard. What I heard was the contrary, IOW, the tracks would not be completely aligned at first (had an echoey effect) until after I stopped and re-started playback, then they were in perfect sync. Is this what you're doing or am I doing something wrong?

Mark,

You're confusing the "Timing Offset (msec)" box with the "Manual Offset" box (which is found down lower on the left side of the Audio Options window). You want to use the latter for the sample offset. Take your roundtrip latency of 655 samples, minus the ASIO Reported Latency (???), minus the I/O buffer size of 128 samples. That will give you the number of samples you're gonna input in the Manual Offset box. Be sure to verify the results by doing the other latency test (the one for both ASIO/WDM).


Hope This Helps!

I have been using Cakewalk software since 1988.
I have been fighting the audio/timing/crakels/dropouts
thru the PC evolutition since then.
I have owned every version of Sonar 1-7
When I 1st. installed Sonar 7.00, things were looking great.
Then the patch updates came along.

I didn`t notice anything negative on patch 7.01,
right after 7.02 then things started acting up.
Not all at once, little by little as I started to add
more audio tracks to my recordings.

Last night, I uninstalled Sonar, all USB to MIDI dvrs.
Then I re installed Sonar 7, (NO PATCHES YET)

I used to use the OPL MIDI interface for the Motif RACK ES
tone editor from Yamaha while running Sonar, but not anymore.
It was a source of major timing errors. (GUI editor).

I also found a newer USB to MIDI interface at Yamaha`s web site,
so I installed it. dvr date: 2/5/08
My M-Audio Delta LT1010 driver is the latest from the web too.

I re-recorded 3 stereo guitars tracks, Audio to MIDI Timing is much better,
I wouldn`t say it perfect, but a far cry better from last week.
(I`ve also done the loop calibration test as recomended on other threads)

What I do hear that I`m concerned about is when mixing down multiple
audio tracks (say 8-12 aud trks) the audio starts to sound distorted.
Even though all the Meters show the nominal green in the SAFE area
including the MASTERS out. (no effects anywhere)
I get great audio when Im soloing several tracks (4-6) at a time,
as soon as I kick in the other 2/3rds, I hear distortion while not
overdriving the channels. Anyone else experience similar issues?
anyone know of a simple tweak?
Thanks
Donny B

Mark,

First of all, ASIO and WDM are two completely different driver models hence the latency test will show different results on both.

Secondly, Sonar uses ASIO Reported Latency (ASIO drivers only of course) to automatically compensate for most of the driver's latency hence the Manual Offset for it will be much less than what it is for WDM.

Thirdly, different interface companies develope their driver models differently. Some have more efficient ASIO drivers while others have better WDM drivers, it just depends. So you need to test both driver models before deciding which one works best for your system (specially under heavy CPU stress at low latencies). So if you use both driver models you'll need to perform the latency test on both.


Hope This Helps!

Understood. but I thought things were closer than that to begin with so I did a total retest in WDM since ASIO was fine. And I had to enter an offset of more than 1400 samples to get things even!

This goes to support my experience that MOTU has suck a$$ windows drivers. I already know they have no respect for supporting people with the platform,....

Guess I'll be in ASIO from here out.

yes Jim, ping tool! The only logical tool for a very significant issue with Sonar recording!

Internal ping tool should be an integral part of the app.

And ability to store a couple optimized latency and buffer user set-ups- for "user 1 tracking set-up" and "user 1 mix down set-up", with the results of the ping, so with a shortcut keystroke you could easily change overall state, latency-wise, from tracking (shortest possible latency) to editing-playback setting (plenty computing time) setting. Kinda like a repro/sync head switch, only addressing a main latency switch.

ping tool should be an integral part of better latency management in the app. Would be huge for me!

Rock on, Jim.

Ev

Does a test for WDM exist that is equivalent to the Centrance latency test utility?

Does anyone know the things that can be done to the settings to tighten down recording midi to audio? Mine midi to audio uaually records ahead of where it's supposed to be and is very erratic.

Are you talking about rendering MIDI to audio with a soft synth, or driving an external sound module and recording the output? MIDI to soft synth should be pretty good, although the MIDI Jitter thread identified some issues with specific soft synths. MIDI to external sound modules will tend to be produce audio tracks that are late, and slightly more variable due to MIDI delay and jitter issues, but it's usually tolerable or easily compensated. Geting early audio from either a soft synth or an external sound module is a little unusual. Tell us a little more about the circumstances, and the quantitative severity of the discrepancy you are seeing, and we might be able to point you in the right direction to resolve/mitigate it.

Edit:

Do we need another thread?

This might be a good idea, actually.

Concerning the loop back test, I have the understanding that this directly correlates to usage in a send-return application, in this case the time it takes to go from D-A out and A-D back in. But when recording, we are only doing half of this process - A-D. So are we to divide in half our loopback test result (for a close estimate)?

Ah I see, thanks Jose!

I set up a midi track 2 measures long with 1/8th notes quantized. Outputed midi track to TD8, Recorded audio to track. Most of the time the audio records ahead of where it is supposed to be. I recorded about 6 times and none of the tracks line up. Also each beat is different, on each track. I have played with everything that I could find.

Well, until this thread moves somewhere else:

In my experience, the only way audio ends up earlier than the MIDI driving it is if the audio is coming in from an external sound source and being overcompensated by Sonar's latency setting. So the first thing I would do in your case is disable Reported Latency compensation, zero any manual offset, and repeat your MIDI-driven TD8 test. If you still get external audio coming in ahead of the MIDI driving it, then I don't know what's going on, but I'd be really surprised at that result.

Another thing you should do, if you haven't already, is a simple MIDI loopback test to see how stable your MIDI timing is by itself. As I see it, the irregular timing you are seeing could come from any of four sources: poor MIDI Out timing, poor MIDI response from the TD8, irregular A/D conversion or buffering of the incoming audio, or mishandling of the incoming data by Sonar. The latter three would all tend to result in really audible distortion of recordings, so it seems most likely that you have problem with your MIDI Out clocking.

If the MIDI loopback test comes back pretty clean, the next thing to try would be to add the TD8 to the loop, using its MIDI Thru to return the data, and seeing if the timing of direct-monitored audio from the TD8 sounds as regular during recording as the re-recorded MIDI. If the timing is off at that point, then the TD8 has a MIDI response problem. If the timing is good during recording, but is off in the recorded audio track, then the problem is in the audio buffering/Sonar handling part of the process.

Of course, this assumes that the timing errors are bad enough to be easily audible. You haven't mentioned how far off things are. If we're talking about 1- or 2-millisecond errors, that's going to be harder to nail down.

And finally. I wouldn't rely too heavily on Sonar's placement of transient markers in audio to determine timing accuracy. The only way to be sure is to zoom in the audio and pick out the beginning of transients manually.

Possibly, but if he has existing audio and MIDI that are both in sync with the time ruler, and new audio is being recorded out of sync with both of them, the offset won't be able to correct that. Also, he's reporting irregular timing, which needs to be understood and addressed separately.