ORIGINAL: brundlefly

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.

Oh I see. In that's the case he's MIDI interface is the most logical culprit here since Sonar is aligning Audio and MIDI correctly. He should test this using another MIDI interface (if possible) just to rule Sonar out.

Okay, I'm testing my new LynxL22 card, but I'm finding it hard to trust the results I'm getting, at least using CEntrance.

I'm running the analog out into my mixer and back out through the aux out to the Lynx. I need to figure that into the latency, correct?

When I choose the Lynx in CEntrance it pops open the ASIO control panel and when I click okay it gives me the message "The driver requested ASIO reset." And when I click through that it throws me back to the Lynx control panel. In an endless loop until I cancel. It seems to work from there. But really, the numbers it gives me don't help when I try the kick-drum test, just shift the problem around.

So using that project that I set up back in S6 to test back then. And I ran that and was able to get results that seem less all over the map.

Thanks for doing the leg work on this, man.

ORIGINAL: riojazz

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

i'd like to know this too, more out of curiosity.... what true roundtrip latency i am getting with my audiophile192 under wdm


it's just that sonar's wdm performance, on my machine, with the delta, is way ahead of the asio performance, less pop click prone, and WAY less dropouts.

but i am wondering if 64 samples wdm is the same as 64 samples asio, in sonar.

ORIGINAL: brundlefly
If no one comes up with a WDM-compatible applet, you can just do the manual loopback, test: re-recording an audio track with no compensation enabled, and determining the actual round-trip latency by zooming in and finding the difference in samples between matching waveform features.

Yes, I prefer that method, as it measures the delay directly in SONAR, where you are then entering the correction value. Theoretically it shouldn't matter, but a separate tool adds uncertainty just in the assumptions that the other tool makes. (Of course, others may prefer the convenience that the CEntrance tool offers. If you're on ASIO, it's ultimately just a matter of preference.)

Yes, I prefer that method, as it measures the delay directly in SONAR, where you are then entering the correction value. Theoretically it shouldn't matter, but a separate tool adds uncertainty just in the assumptions that the other tool makes.

I had done a number of tests manually before getting turned on to CEntrance. CEntrance has yielded results identical to the manual method in all cases I've tested, and it does simplify the task considerably. In particular, it made it very easy to determine that I can use a fixed offset together with the ASIO Reported latency to get consistent compensation no matter what my buffer settings are with the 1820m.

I am wondering, I will always record my vocalist with software monitoring (as he likes a confidence reverb) and use 128 sample buffer when he records (safer than 64 and not too much latency difference)

BUT.... I guess if we are doing music that requires REALLY tight timing, we are going to get delayed audio AGAIN because of the monitoring latency? I mean he cant be 100% precise when there is 8ms roundtrip latency or whatever it was when I tested it (7 or 8. something)

????/

OK!!! The delta audiophile 192 is EXACTLY 80 samples offset, in WDM at 128 sample buffer! Now the tracks line up PERFECTLY!

PRAISE JOSE!!!


Now, the final question.... According to Centrance, the roundtrip latency of my card, at 128 sample buffer, in ASIO mode, is a best of 7.57 ms and a worst of 7.64... pretty good!

But I still have to do some tests now to work out true roundtrip latency, at 128 samples, in WDM mode, i wish ceentrance did this!

I have some more VERY interesting results. Using the same audio file, same sample buffer of 128, on an empty project in Cubase 4, using the ASIO driver, cubase recorded everything 2 samples early, big deal,. it's not noticeable. But Cubase has a field to adjust the record latency so i put it at MINUS 2 and it lines up perfectly, although honestly, the reason i never noticed it before, is because, well... 2 samples LOL.

NOW, sonar 7.02 in ASIO mode, with the asio automatic compensation box thingie ticked, was still 165 samples out (late)!! double WDM.

SO, there is clearly something wrong with SONAR here. There is no other way to put it, it is obvious sonar has a problem in this area.. there are no variables in place, same sound card, audio file, driver etc.....

ORIGINAL: DeeringAmps

ttoz,
If the tracks line up with an 80 sample offset, isn't the round trip 80 samples?
It sounds like in your system the WDM driver works best, doesn't it?

I always monitor off the mixer (hardware) and "sweeten" the vocal there. However, I would think that the "delay" for the processed reverb could be viewed as "pre-delay". Just shorten the pre-delay in the preset to suit. Right?

Am I "getting" the math here?

The roundtrip couldn't possibly be 80 samples when at minimum the buffer is 128 each way PLUS 80 hidden is the way i understand it.

fallibility. Some one mentioned that Cubase just works in asio mode. I must agree! But then again they invented the thing. Tell me when Cakewalk plan on making there own so we do not have to discuss these timing issues anymore. I agree also that there is some type of fault with Sonar in this regard. Can anyone make me it humble pie????

Cakewalk for instance.

Don't get me wrong Sonar does some good things but I am pining for Cubase at the mo!

Though I must state again that Sonar is good or just as good as any other sequencer. Better I cant say any other is better, better in some areas yes!

that Roland Fantom x looks good for sequencing. I dont know I just need a good alternative that is trouble free

Ttoz,

You have asked some very good questions and I'm not sure if I'll be able to answer all of them correctly but I'll try. From my understanding, most manufacturers design their drivers with hidden or safety buffers as to ease CPU load and reduce Dropouts/artifacts at low latency settings. They might also design their drivers to report the converter's latency to the software. For example, I know RME's drivers have a fix safety buffer size of 64 samples (~1.5 ms) on the playback side only which is reported to the software (in this case Sonar) together with a A/D and D/A latency of 2 ms (~80 samples). This means that at a buffer size of 256 samples I should end up with a roundtrip latency of ~656 samples (256 * 2 + 64 + ~80 = ~656) which is pretty much what I got with CEntrance if you look at my previous posts. Of course this is easily confirmed with CEntrance but it only works for ASIO drivers not WDM. So, basically, you'd never know your true WDM's rountrip latency unless your audio interface manufacturer tells you what the latency of their hidden buffer(s) is because it might've been already compensated by Sonar. This is probably why a lot of people end up with early recordings when using WDM drivers. In conclusion, your 80 samples offset must come from the A/D and D/A conversion while everything else is being compensated by Sonar. On the other hand, if you have performed the latency test then none of this really matters because either way your system is now sample accurate since everything has been accounted for (hidden buffers and all).

Now your other question is the tricky one to answer. I know that if you monitor through Sonar everything will be automatically compensated through the manual offset, but I'm not sure what happens if you monitor directly from your interface though. This is something I would like to know as well.

LAST question, let's say all is good, and the wdm roundtrip latency is truly 336 samples. My vocalist, might be performing a tight timing essential vocal (let's say a fast rap just for example), and his monitoring will be going through sonar so i can give him a confidence reverb. So he is going to have 336 samples of monitoring latency. Wouldn't THIS then need to be adjusted manually as well once recorded? Or is this what the above test has been for?

I mean, if i were to record a vocal with direct monitoring, no software reverb etc, there'd be essentially no delay so this would be recorded WITHOUT needing any value in the manual recording latency adjustment field, correct? Because we are bypassing sonar altogether here.....

This is a really interesting question that I've been meaning to think through for a while. Here's what I've concluded:

It all depends on how much subconscious latency compensation the vocalist does himself. Think of it this way: If he/she is singing to existing audio playing back from Sonar with his own voice input-monitored, he is going to have to sing ahead of the beat by half the round-trip latency to have his vocal sound in sync with the audio in his headphones, because the audio has only made half a round-trip (out only), while his singing has made a full round-trip (in and out).

The question is will the vocalist fully compensate for this delay so that his voice sounds in sync as he sings, or is he going to sing on the beat as he hears it, and ignore the fact that this voice sounds a little late? I'm guessing that most singers are going to automatically compensate for most of the delay if it's not too great. If his compensation is perfect, Sonar is actually going to be over-compensating by half the round-trip, and the vocal will end up being placed early relative to the existing audio.

Now suppose he monitors himself (i.e. the mic's output) directly. As before he hears the audio with half the latency, and sings in sync with what he hears, but this time, there is no delay between his larynx and his ears, so to speak. Thus, he sings right on the beat of what he hears, which is late by half the latency, and his performance goes into Sonar with the other half of the round-trip latency. In this case, Sonar's compensating by a full-round-trip latency should sync the new track perfectly with the existing one.

In either case, there is no additional latency compensation to be done. If anything, the input monitored performance is going to have to be "uncompensated" by some amount to account for the singer's automatic compensation.

Incidentally, the same should apply to instrumental performances. So an argument could be made that Sonar should only compensate for half-the round-trip latency when input monitoring, because the performer will subconsciously compensate for the other half.

I think I've got this right. But I'm open to alternate opinions.

And I don't even want to contemplate how MIDI fits into this.

Jose, I need to think about what you've written, but in the mean time, I did a quick test that pretty much confirmed what I expected, except for one thing: Latency is not divided equally both ways. The buffer latency only applies on the outbound side, while the D/A and A/D conversion are roughly equal. This makes snese, as there's is no reason for input buffers other than what the A/D converters do.

So here's what I did:

I set up an audio track with quarter notes playing right on the beat, and upped my latency to 100ms! Turned off all latency compensation and monitoring. Listened to the playback, and recorded new MIDI and audio tracks from my keyboard, playing silently, and just focusing on hitting the keys in sync with the audio beats. This is essentially what you would have with direct monitoring. As expected, the MIDI events were pretty much right on the audio events, but my recorded audio ended up about 100ms late everywhere because it wasn't compensated either by me or by Sonar.

Now I enabled input monitoring, and repeated the test, trying to ignore the timing of my fingers, and focus on aligning the input-monitored audio with the audio playback. This was difficult with 100ms latency, but after a little practice, I got to the point where the MIDI was being recorded very early, and the audio was close to synced up - with no compensation by Sonar.

Now I enabled ASIO Reported latency, and recorded while input monitoring. As before, the MIDI was 100ms early, but now with both me and Sonar compensating for latency, the audio was also 100ms early!

So if you're re-recording existing audio via a loopback test or a live performer who is using direct monitoring, it's important to have the latency fully compensated. But if you are recording a live performer who is using input monitoring, the performer may well do most or all of the compensation for you.

Edit: Clarified the last paragraph to indicate that a direct-monitored performance needs to be fully compensated.

ORIGINAL: brundlefly

Latency is not divided equally both ways. The buffer latency only applies on the outbound side, while the D/A and A/D conversion are roughly equal. This makes snese, as there's is no reason for input buffers other than what the A/D converters do.

That's not true either. You DO have Input buffers when recording audio, so latency is equally divided (with the exception of hidden buffers). When you set up a latency of 128 samples, Sonar only reports the Output playback latency (without extra buffers or A/D conversion) but there's also an Input record latency of 128 samples with D/A converter latency as well.

Regarding your test, it would be hard to prove anything the way you're going about it since there's a lot of human error being introduced into the timing (specially since you're delaying things by 100 ms). I'm not saying you have bad timing or anything, but it's just impossible to get perfect timing this way because we're not machines and are always subject to add our own timing errors (which is what makes music human anyways). Not to mention that you're also introducing another latency factor, MIDI latency.


Take care!