# Loopback and timing reference



## Castore (Oct 13, 2009)

I have been using loopback timing reference to measure speaker distances from the microphone tip (=listening position). I got realistic distances (calculated from the impulse response delay times) with my older soundcard M-Audio Fast Track Pro (Java), but the new Focusrite Scarlett 18i8 (ASIO) gives totally different results (about 2m vs. 4.3m, the longer distance being faulty). *What could be the root cause for the error and can it be eliminated?* REW Help doesn't give advices to that. Although relative delay is more important than the absolute, I would like to solve this anyway, if possible. I'm a bit concerned that the error may not be constant. There is a feature called "Latency Tracking" in the 18i8 which I haven't tried yet. 
*How accurate can the delay time value be and what are the error sources?* Using the delay time measurement I have managed to match the speaker distances to about 1mm accuracy which gives a nicelly ideal left/right sum response, accurate stereo imaging being the final target. 
That is also a handy method for placing the measurement microphone to exactly the same position as it was in an earlier measurement, given of course that the speaker positions remained unchanged.

I'm running REW in Win8.1 laptop.


----------



## jtalden (Mar 12, 2009)

The delay to the recorded impulse response includes the delays in all the DAC/ADC processes in the measuring system. The buffer size / latency employed by those processes are necessary and cannot be completely eliminated. They most often can be adjusted as is the case with both the audio interfaces you mentioned. The DAC in an AV receiver and its distance settings are another common source of delay.

As you mentioned, for home theater/stereo applications we normally don't have any reason to be concerned with the total delay, only the relative delay so we normally just set a safe buffer size to assure there is no dropped data during our measurements. Your mic placement example is a typical case where the result is same whether the delay is removed or not.

One can determine the total measuring system latency using various methods if it is really needed for some reason.


----------



## bentoronto (Dec 3, 2010)

jtalden said:


> One can determine the total measuring system latency using various methods if it is really needed for some reason.


Can you please elaborate on the methods.

I have a few sources of delay in my system, including a USB/AES converter, Behringer DCX2496 DSP box, mic ADC, not mention the usual elements internal my laptop and distance from speakers to the mic.

Given these delays, I'm confused about REW moves its analysis windows so as to relate instantaneous mic input to delayed REW audio output? Or how can I measure and/or correct to ensure correct measurements?

Also, my MacBook Air, OS 10.11.4, doesn't seem to have access to loopback'ing that I can find.

Thanks.
Ben


----------



## jtalden (Mar 12, 2009)

Ben,
I assume you read the info starting *Here* regarding acoustic timing. That feature will effectively remove any measuring system delay variability.

I can probably help with specific questions. What are you trying to do? Do you want to determine the needed delay to create close phase tracking between drivers when using the DCX for XO? Are you just having trouble getting the acoustic timing setup and working properly?

If I know what you are trying to do and a better idea of where you need help, I may be able to assist.


----------



## bentoronto (Dec 3, 2010)

jtalden said:


> If I know what you are trying to do and a better idea of where you need help, I may be able to assist.


Many thanks for link. Oddly, my Mac V5.15 beta 2 version doesn't think there is an update to beta 3, as the link mentions. At the download forum, there are quite a lot of recent Mac OS versions!

My question is this:

Recently, I got a ragged-looking FR, running REW through my newly implemented mostly-digital system. So I started worrying that REW must be using a moving window as the stimulus signal sweeps up the scale (I assume you can't record sweeps any other way). But what if there is a big time delay in the stimulus path that is a lot longer than the usual 15 milliseconds delay for the sound to go 15 feet from speakers to mic? In that case, the mic is out of step with the REW stimulus signal and requires a time offset to work correctly.

And I don't know about loopbacks, unless that means using the right REW output fed back to the right laptop input (as when using the left channel to drive the speaker).

I don't know if that makes any sense.

Ben


----------



## jtalden (Mar 12, 2009)

bentoronto said:


> Many thanks for link. Oddly, my Mac V5.15 beta 2 version doesn't think there is an update to beta 3, as the link mentions. At the download forum, there are quite a lot of recent Mac OS versions!


I also get no notifications of Beta updates other JohnM comments in that thread.



> Recently, I got a ragged-looking FR, running REW through my newly implemented mostly-digital system.


I understand that with your room setup and another simpler signal path the response was significantly smoother. I have no immediate thoughts as to the cause of this. Without changes to the mic and speaker positions in the room or to the room treatments I would not expect major changes. It would be good to confirm that there is no variability in several repeated measurements. If there is then that is a problem.



> So I started worrying that REW must be using a moving window as the stimulus signal sweeps up the scale (I assume you can't record sweeps any other way).


My understanding is that there is no moving window tracking the frequency sweep. There is a large FFT block capturing the response including significant pre and post sweep to accommodate various delays. With no loopback or acoustic timing activated REW positions the IR to 0ms for convenience and then applies a window 125ms prior to and 500ms after the peak. This window is adjustable as needed for some types of analysis.



> But what if there is a big time delay in the stimulus path that is a lot longer than the usual 15 milliseconds delay for the sound to go 15 feet from speakers to mic? In that case, the mic is out of step with the REW stimulus signal and requires a time offset to work correctly.


I previously was using relatively large buffers and with my 14' LP my total delay was about 110ms... no issue. We can make a measurement and immediately check the 'Scope' panel to see both the sweep output and the captured response. It also shows the captured pre and post capture (excess time). If part of the response is not captured, that is a problem.



> And I don't know about loopbacks, unless that means using the right REW output fed back to the right laptop input (as when using the left channel to drive the speaker).


Yes, The REW timing features (loopback cable or acoustic) is not needed for EQ work and many other common uses of REW. 

When we are trying to determine the delay needed to aligning drivers using a DSP XO like the DCX (or doing other similar relative timing work) then it is necessary to use one of the 2 REW timing features so that all captured IRs are located relative to the same starting time rather than being automatically moved to 0ms.


----------



## jtalden (Mar 12, 2009)

Ben,
In some earlier REW beta versions the automatic window positioning did not seem to always locate itself to the IR position as expected when the IR position was manually shifted. It's easy to confirm the applied window is properly placed by activating the 'Window' check box in the 'Impulse' panel so the window position is shown on the chart. Just manually locate it as needed if there is a problem.


----------

