REW loopback timing synchronisation for separate DAC/ADC via DAW

Hey everyone, this is my first post here and I hope to contribute something useful. If this topic has already been covered, please accept my apologies. My statement below is not based on a deep understanding of REW's internal architecture and does not claim to be definitively correct, but it is derived from the empirical observations described.

To the point: If you’ve ever dug through the manual und the forums trying to set up an electrical loopback timing reference in Room EQ Wizard (REW), you’ve probably run into this golden rule: "Input and output MUST come from the exact same audio interface."

While that's safe advice, it actually rules out a ton of awesome setups. What if you want your very capable multichannel DAC (e.g. my Topping DM7) to handle playback, but a separate great interface (like my Audient iD14 MKII) to do the measurement?

Direct answer first and the only catch: You can absolutely split your playback and recording hardware. In fact, you can even run them at completely different sample rates, and your timing reference will still remain rock-solid. The only hard software requirement is that you must use a DAW, a software router, or a media center (like JRiver, Reaper, VoiceMeeter, etc.) capable of copying your active measurement channel to a spare output in real-time.

Sure, you could use REW's acoustic timing reference instead, but it has its drawbacks, which (I believe) I don’t need to go into further detail about.

Here is the good news: You can absolutely split your playback and recording hardware. In fact, you can even run them at completely different sample rates, and your timing reference will still remain rock-solid.

The Key Insight: It's all about the ADC, not the DAC
Clock drift between your separate playback DAC and your measurement interface doesn't matter at all. Why? REW doesn't care about absolute time (at least, that’s how it seems to me based on what’s covered here). It only computes the relative difference (the delta) between its two input channels.

As long as both of your REW inputs - the timing reference cable and the microphone - plug into the same measurement interface, they are digitized by the exact same ADC clock. If the playback DAC drifts and sends a sample 5 milliseconds late, that delay hits both inputs at the exact same time and completely cancels out mathematically.

In JRiver, I route the left or right channel as a copy to the otherwise unused center channel (Out 3) of my Topping DM7. The latter is routed via cable into the right (In 2) input of my Audient ID14 MKII as a loopback for the timing reference.

The "That just won't work" Stress Test
To push this theory to its absolute logical limit, I set up a deliberate sample rate and driver mismatch nightmare. Normally, mixing different audio driver architectures in Windows is a recipe for unstable buffer latencies and timing drift. For this test, the signal had to survive three completely different driver layers:

1. REW to JRiver (Java Audio): REW generates the sweep and sends it via the standard Windows Java driver interface to JRiver WDM driver.
2. Inside JRiver (WDM Kernel Streaming): JRiver's WDM driver captures the stream, brings it into the DSP engine for real-time resampling, duplicates the left or right channel and routes it to the center channel (Out 3)
3. JRiver to DAC (ASIO): The final resampled audio is handed over to the ASIO driver of the Topping DM7.

The Playback Chain: REW (via Java driver) → JRiver WDM Driver → JRiver DSP Engine (forcing real-time resampling and copying the signal) → Topping DM7 Multichannel DAC via ASIO.



The Recording Chain: Measurement microphone connected to the Audient iD14 mkII, accessed via REW's Java driver.



The Hard Data
I tested all four permutations of sample rate combinations between REW/ADC and the playback DAC. Here is what REW recorded under the hood:

Test Case 1: REW 48 kHz – DAC 48 kHz (The baseline)
Delay: 2.9192 ms | Clock adjustment: 140.1 ppm
Test Case 2: REW 48 kHz – DAC 44.1 kHz (Resampling active!)
Delay: 2.9191 ms | Clock adjustment: 139.5 ppm
Test Case 3: REW 44.1 kHz – DAC 44.1 kHz (Native 44.1k)
Delay: 2.9193 ms | Clock adjustment: 139.4 ppm
Test Case 4: REW 44.1 kHz – DAC 48 kHz (More resampling!)
Delay: 2.9192 ms | Clock adjustment: 140.1 ppm

Maximum Observed Deviation: 0.0002 ms (0.2 microseconds) / 0.7 ppm

Think about that: Despite forcing real-time software sample rate conversions (SRC), shifting driver buffers, and completely independent hardware clocks, the timing did not budge. A variation of 0.2 microseconds is mathematically invisible for acoustical analysis.

To visualize this, take a look at the attached screenshot below. It shows the Impulse Response Overlay of all four test cases zoomed in to the microsecond level. They line up perfectly:




Why this works (The Quick Math):
Some might argue: "But the clocks still drift while the sound travels through the air!"
Let's do the math for a standard 3-meter (10 ft) listening distance:
1. The sound takes about 8.8 ms to travel through the air. This is the only window where the clocks are decoupled.
2. Even with a terrible clock drift of 50 ppm, the drift accumulated during that tiny 8.8 ms window is just 0.00044 ms.
3. At 48 kHz, a single sample is 0.0208 ms. Our worst-case error is roughly 0.02 samples.

Long story short: The sweep is simply too short for clock drift to matter.

If you want to replicate this (ideally keeping everything at a matching 48 kHz for sanity's sake), just remember these two things:

• Keep your Software Routing Stable: If you copy channels or resample, use a rock-solid engine like JRiver's WDM driver or a proper DAW matrix. Avoid standard Windows MME/DirectSound mappers, as they introduce random buffer latencies between sweeps.
• Check the Phase: Make sure your routing software doesn't accidentally invert the phase of your copied loopback channel.

The .mdat files are attached below for anyone who wants to examine the data. If you have the software routing capabilities, feel free to replicate the test and let me know if it works just as flawlessly in your system. I’m curious to see what the REW experts and veterans here think about this approach!

Thanks for reading!

Too difficult. The concept of standard listening distance cannot always be used. What if you need to measure at a distance of 20 m, or 100 m? Such cases have been discussed here more than once.
To make the input and output work with different devices, REW has Java drivers. This is used by everyone who sets up home theaters.

I think you are confusing two entirely different technical concepts here: acoustic propagation delay and operating system driver limitations.

Let’s first consider the calculations for extreme distances. Even when measuring a massive venue at a distance of 100 meters (which corresponds to an acoustic runtime time of about 290 ms), the cumulative deviation between two asynchronous clocks with a deviation of, say, 50 ppm during this time window is only 0.014 ms. At 48 kHz, that is still less than a single sample. So even in a stadium, the clock deviation during the sweep remains mathematically irrelevant to the impulse response. In practice, no one would lay a 100-meter-long analog loopback cable across a stadium anyway. For such distances, the professional audio industry provides synchronized network clocks (such as Dante/AES67).

Second, your explanation of the Java drivers is technically incorrect. REW does not use the Java audio subsystem to 'make different devices work seamlessly together' regarding clock synchronization. REW uses Java simply because Windows allows the aggregation of two separate USB audio devices under Java (like a USB UMIK-1 and an HDMI AVR), whereas the ASIO standard strictly limits you to a single hardware device per instance.

However, using the Java driver does absolutely nothing to solve the physical clock drift between those two separate devices. An USB mic and an AVR will still drift independently.

My guide is specifically for users who want to avoid the inherent drawbacks of the acoustic reference while maintaining the luxury of separate playback (DAC) and recording (ADC) hardware. The Java driver is just the software pipeline to open the channels; the shared ADC clock domain is what actually guarantees timing accuracy.

I didn't even mean 100 m of loop cable. Of course, only acoustic synchronization. REW can detect and compensate for differences in input and output clock rates. I always use acoustic synchronization. It's reliable and simple. Your calculations show minimal error for your method. But it's better to wait for John's answer to find out how justified your method is.

sm52 said:

But it's better to wait for John's answer to find out how justified your method is.

Click to expand...

I'm looking forward to that, too...

TheLastGerman said:

Input and output MUST come from the exact same audio interface

Click to expand...

Who says that?

There's no need for the input and output device to be the same. I wouldn't recommend operating input and output devices at different rates, that's a recipe for trouble. With the "Adjust clock with loopback" Analysis preference selected REW will accommodate the clock rate difference (140 ppm for the examples). Short term drift in clock rates is negligible, temperature variation is the main contributor.

John, can you please correct me if my understanding is wrong: if input and output are on different devices, then the OS scheduler may start them at different times. This causes latency jitter which results in unreliable timing measurements. So according to this understanding, I would have thought that @TheLastGerman's statement was correct?

Hi John,
thank you for chiming in and providing the definitive explanation from the source!

To answer your question 'Who says that?': This 'rule' is widely repeated by users across various audio and home theater forums whenever someone asks about using a separate DAC and measurement interface. To me it seems it has practically become dogmatic forum wisdom... Hearing that REW natively accommodates this via the 'Adjust clock with loopback' preference explains perfectly why the data is so rock-solid under the hood.

However, I think the heart of this specific setup might have been buried in my text: The key is using JRiver’s virtual WDM driver as the pipeline.
Normally, if you try to route a REW sweep through a complex, separate multichannel playback engine with an active DSP crossover (with all filters, routing, and time-alignment engaged), that will introduce unpredictable, variable buffer latencies that make reproducible timing impossible.

By utilizing JRiver's WDM driver to accept the sweep from REW, JRiver handles the channel replication to the spare DAC output with an absolutely rigid, fixed buffer latency. That is the only reason the 44.1k / 48k mismatch stress test worked so flawlessly without causing a total sync failure in the OS.

So while I completely agree that running different rates is a recipe for trouble in standard environments, the JRiver engine acts as a bulletproof buffer that makes measuring a separate, live DSP crossover system completely painless.

Thanks again for your insights and for creating such an incredible tool!

Keith_W said:

if input and output are on different devices, then the OS scheduler may start them at different times. This causes latency jitter which results in unreliable timing measurements

Click to expand...

No, because all timing is relative. The loopback connection provides the reference for the input. It doesn't matter when the output starts, the relative timing of the loopback and the input is preserved. That's just as true even if input and output are on the same device, the replay and capture paths can be completely separate with their own buffers, buffer sizes and latencies. That's why the timing reference is needed in the first place.

John, why are you only writing about loopback connections? Is acoustic synchronization also reliable for determining the exact impulse timing in all cases?

sm52 said:

why are you only writing about loopback connections

Click to expand...

Because that's the topic of the post.

sm52 said:

Is acoustic synchronization also reliable for determining the exact impulse timing in all cases?

Click to expand...

Usually. Nothing is perfect, strong reflections can interfere with the detection of the acoustic timing signal.

John Mulcahy said:

Because that's the topic of the post.

Click to expand...

Thanks for the answers. I didn't read the main question of this thread carefully.