TheLastGerman
Active Member
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 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 multichannel DAC (like my Topping DM7) to handle playback, but a separate interface (like my Audient iD14 MKII) to do the measurement?
Direct Answer First & 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.
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? Because REW doesn't care about absolute time. 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 (3) of my Topping DM7. The latter is routed via cable into the right 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 the virtual JRiver soundcard (JRiver WDM driver).
2. Inside JRiver (WDM Kernel Streaming): JRiver's virtual WDM driver captures the stream, brings it into the DSP engine for real-time resampling, and duplicates the channel.
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:
Thanks for reading!
Find the .mdat files here.
To the point: If you’ve ever dug through 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 multichannel DAC (like my Topping DM7) to handle playback, but a separate interface (like my Audient iD14 MKII) to do the measurement?
Direct Answer First & 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.
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? Because REW doesn't care about absolute time. 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 (3) of my Topping DM7. The latter is routed via cable into the right 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 the virtual JRiver soundcard (JRiver WDM driver).
2. Inside JRiver (WDM Kernel Streaming): JRiver's virtual WDM driver captures the stream, brings it into the DSP engine for real-time resampling, and duplicates the channel.
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.
Thanks for reading!
Find the .mdat files here.
Last edited:
