ORIGINAL: Jose7822

With ASIO, on the other hand, you can open your audio interface's Control Panel from the Audio dialog window in Sonar by clicking the "ASIO Panel" button

this is what i referred to as sonar's asio box. sorry for the misunderstanding.

ORIGINAL: Jose7822

I still don't understand that set column though, can you explain? Maybe this is something your interface does differently than mine?

Nevermind, I figured it out. That sure is an odd way to change latency. I'll let you know if I find an answer for you concerning your results.


Take care!

ORIGINAL: ru

no...by 'set' i just meant the asio latency in ms. i was trying to save space on the graph...not realizing it was causing more trouble than it was worth :D

Yes you did, specially since you already had the ms numbers in there. My head is spinning because of you .

I can't figure out why you got those results, although I doubt they affect anything other than the disk activity. I'll give it a try tomorrow to see what I come up with .

using the basic procedure you've outlined, i had 182 - 159 - 88 = -65.

There's something wrong with your roundtrip latency, unless your audio interface is actually moving the recorded audio data back to automatically compensate for latency (in which case this would be correct). Man, there's so many variables.

so this won't affect older projects? only how accurately a track is recorded, not played back?

No, this will not affect older projects. It only affects recorded data.

I think there are 2 kinds of "hidden" latency, and they have different implications with respect to timing error.

A, The amount of fixed buffering (soundcard DSP, converters etc). These are always the same size in samples, and therefore introduce less timing error at a high sample rate than they do at a lower one.

B. The "real" amount of user adjustable buffering. Some drivers double-buffer. This may not be so noticable at 64 samples set and 128 "real", but is really bad at 512 set and 1024 "real". This therefore introduces higher offset error when the latency buffer is increased.

ORIGINAL: jim y

I think there are 2 kinds of "hidden" latency, and they have different implications with respect to timing error.

A, The amount of fixed buffering (soundcard DSP, converters etc). These are always the same size in samples, and therefore introduce less timing error at a high sample rate than they do at a lower one.

B. The "real" amount of user adjustable buffering. Some drivers double-buffer. This may not be so noticable at 64 samples set and 128 "real", but is really bad at 512 set and 1024 "real". This therefore introduces higher offset error when the latency buffer is increased.

Interesting, that totally makes sense. I just learned through this experiment that mine is the type A kind where there's a fixed amount of buffers regardless of the latency and possibly the sampling rate (I've only tested 44.1 KHz and 48 KHz but not higher). The question is, shouldn't CEntrance be able to detect the "real" latency amount of those drivers that double-buffer? Like in Ru's case, he's results don't seems to show the whole truth with CEntrance. Also, how come some audio interfaces appear to be moving audio back in time (where the recorded audio is to the left of the reference track)? I hope you can answer these questions for me.


Take care!

ORIGINAL: vanceen
Another thing I found interesting is that the samples, even when lined up perfectly, show small but definite differences. I guess this shouldn't be surprising, as the D/A - A/D process can't be perfect. I wonder if the differences would be smaller with a Lynx or an RME?

Well done... that means you are really digging into it! That's right, they can't be perfect, because they did make the transition through analog (and most likely, some small degree of analog filtering on the way out and on the way back in) that adds up to som non-interger sample delay.

Except for a very special set of filter types (e.g. Bessel, Gabor, and phase-equalized types), the delay will be slightly different at different frequencies as well. But that effect is more secondary, and should only occur at the band edge anyway. I hear that the Lynx (for example) has very high-quality converter design, and so it may feature one of those special filter types in its analog section as well (they are more expensive to make while at the same time keeping a sharp rolloff characteristic). But even so, it would be unlikely that those analog sections would be designed to produce an exact integer sample of delay.

ORIGINAL: smashaudio

Loopback test revealed 111 samples needed for the offset. ASIO recorded sample looked much closer to the original than WDM! RME FF800.

Thank you! You have confirmed what I've been saying in this forum about the differences between WDM and ASIO drivers in the Fireface. I recently made a comment about this here: http://forum.cakewalk.com/fb.asp?m=1303755 (post #50).


@ Vanceen,

To answer your question, even with the FF400 and ASIO drivers there's still very tiny differences between the original and the recorded file. Like Losguy said, this is expected since the signal is going through the converting process (D/A, A/D). But I wouldn't loose sleep over it. The differences between the two is WAY too small.


Take care!

Ru,

I'm still not getting what's going on here. Why is CEntrance reporting such a low roundtrip latency in your case? A roundtrip latency at 88 buffers gives you 176 samples and your reading says 183 which is only 7 samples more. That's without adding D/A and A/D conversion into the equation, so what's going on? The only reason I can think of is that you're doing the loopback test through the E-Mu software mixer without a cable. Otherwise, I'm lost . Can anyone shed some light here?


Thanks!

Beagle,

It seems that CEntrance will only let you use the current latency buffer that your audio interface is set to. It should automatically bring up your ASIO Panel as soon as you Run it though, so you can make changes there. But then again, the results should be the same regardless of the latency tested as long as it's the same shown in Sonar.

Try this:

- Don't open Sonar and run the latency test at 64 samples with CEntrance.

- Now open Sonar and navigate to Options::Audio::Advanced Tab. It should give you the correct ASIO Reported Latency.

- Follow the formula on the latency test.

- Make sure you have sample accurate recording by performing the second latency test (the one for WDM and ASIO).


Let me know if you're still having problems.


HTH

i am using a cable. the same thought crossed my mind, that centrance was measuring the internal routing of patchmix. but the 'old fashioned' loopback test variance combined with the asio reported latency gets the same number.
sorry if i'm missing some technical aspect here.

Hi Jose

I Have just downloaded the Latency Checker for My Fireface 800, I connected the SPDIF out to the SPDIF in and got a Total Latency of 581 Samples ? Is that correct ? I know my PC is a bit old now but I was expecting better. The Number of Samples setup in my Fireface were 256, If I lowered it to 128 I just get crackles and Pops.

I think some drivers won't let another app change the ASIO buffer settings, which might explain when CEntrance won't do it. M-audio Delta cannot, I'm pretty sure, allow it and it usually crashes if you try. You have to close the app, change the buffer and re-open.

Jim

PS, It's interesting how a click wave looks when it's gone around the loop. There will be some analogue delay because the analog circuits and cable cannot switch that fast - this is really a measure of transient response or "rise time" and something most soundcard testers/reviewers don't test for. I did my settings with a loop round through my mixer - because I'm too lazy to change cables and all I had to do was switch the playback channel to the record bus. Anyway, that really slowed the click, but If I'm within a ms or 2 of "sample-accurate", it's close enough.

PPS, The Delta 1010 inputs have a hardware design fault - input phase is inverted depending on whether you switch to 10dBv or 4dBU levels. I don't have one, but think it's the 10 setting that's inverted. M-audio added a phase switch in the control panel as a workaround.

ORIGINAL: Desperate Dan

Hi Jose

I Have just downloaded the Latency Checker for My Fireface 800, I connected the SPDIF out to the SPDIF in and got a Total Latency of 581 Samples ? Is that correct ? I know my PC is a bit old now but I was expecting better. The Number of Samples setup in my Fireface were 256, If I lowered it to 128 I just get crackles and Pops.

Hey Dan,

I haven't done this through SPDIF but your roundtrip latency measurement of 581 samples sounds correct to me. Mine was 655 through the analog I/O (it's higher because of the conversion). But, in your case, since there's no A/D conversion the results is a lower measurement. You have your I/O buffers or 256 * 2 = 512; And then you take 581 - 512 = 69 samples (~ 1.5 ms) which are probably hidden buffers, so it looks right.

FYI, your computer speed has nothing to do with latency for the same buffer size. IOW, having a more powerful CPU won't lower your latency at the same buffer size.


HTH

Dan,

I read the FF800's online manual and confirmed what I had told you before. If you wanna check it out read Chapter 37.2 on page 96:

http://www.rme-audio.de/download/fface800_e.pdf

It's all there in that chapter.


HTH

Thanks Stratton,

I was actually thinking about doing something like that. Having one post with steps on how to do things like a loopback test, install LAME MP3 encoder, Tips on optimizing Sonar, change your audio latency, calibrating your speakers, etc. I might do it one day for those interested and also so that I don't have to write the same thing over and over .


Take care!