REW 5.40 beta 135 / ASIO401 2.0: Sample rate mismatch (48/96/192 kHz)

[stef1777]

Hello,

I am experiencing a reproducible sample rate mismatch with REW 5.40 beta 135, ASIO401 2.0 and a QuantAsylum QA403 under Windows 11.

Configuration:

- ASIO buffer: 32768 samples
- Input: +18 dBV; output: +8 dBV
- FFT: 256k, Hann, 32 averages
- Test: Q17 Mini amplifier, approximately 1 W into 8 ohms

Observed behavior:

A mains-related spectral peak shifts depending on the sample rate selected in REW:

- 48 kHz selected: peak at 50 Hz
- 96 kHz selected: peak at 100 Hz
- 192 kHz selected: peak at 200 Hz

The 1 kHz test signal remains displayed at approximately 1 kHz. The behavior persists after restarting REW and reconnecting the QA403.

ASIO401 diagnostic log:

WARNING: ASIO host application never enquired about sample rate, and therefore cannot know we are running at 48000 Hz!

The inspected log shows a 32768-sample buffer interval of approximately 682.676 ms, consistent with 48 kHz rather than 192 kHz. No getSampleRate() or setSampleRate() calls were observed in that session. This strongly suggests a mismatch between REW's selected sample rate and the ASIO stream. The hardware sample rate has not been independently verified.

A very similar REW/FlexASIO issue was reported in 2018 and corrected in REW 5.20 beta 2:

FlexASIO doesn't honor the sample rate set in REW · Issue #31 · dechamps/FlexASIO

I've noticed something very strange while experimenting with REW 5.19 and FlexASIO 1.0: when the sample rate is changed in REW, it seems like it has no effect in FlexASIO, meaning that FlexASIO kee...

github.com

Could this be a regression in REW's ASIO sample rate initialization? Does REW reapply the selected sample rate after loading or resetting ASIO401?

Attachments:

- REW screenshots at 48, 96 and 192 kHz
- Anonymized ASIO401 diagnostic log
- Anonymized REW diagnostic archive

I have also reported this issue on the ASIO401 GitHub repository.

Thank you for your help.

 

[John Mulcahy]

REW expects the ASIO driver to honour the sample rate it requests, it calls setSampleRate for the rate it is running at and whenever the rate changes. On startup it queries the device for the rates that are supported (those are the canSampleRate entries in the 401 log) and makes those available in the sample rate selector.

 

[John Mulcahy]

To add to this, after REW sets the rate it reloads the driver and checks the rate it is running at, if the driver reports a different rate REW shows an Error message that the driver rate doesn't match the rate that was requested.

 

[stef1777]

Thank you, John, for these additional details.

I can confirm that REW displays no sample rate mismatch error, even when set to 192 kHz and the mains-related peak appears at 200 Hz instead of 50 Hz.

Meanwhile, the ASIO401 log reports 48 kHz, and the observed buffer timing (32768 samples every approximately 682.676 ms) is also consistent with 48 kHz.

This raises the possibility that ASIO401 reports the requested sample rate to REW while the audio stream actually remains at 48 kHz.

Does the REW diagnostic log record the sample rate returned by the ASIO driver after reloading it?

Is there another way to verify what the driver reports to REW versus the actual stream timing?

I would like to identify precisely where the mismatch occurs before attributing the problem to either REW or ASIO401.

Thank you again for your help.

 

[John Mulcahy]

REW can't tell whether the driver responded or not, it relies on JAsioHost to handle that communication. It calls the native JAsioHost getSampleRate and setSampleRate methods and uses the values they return. It checks the reported host rate whenever it asks for the rate to be changed.

 

[stef1777]

Thank you, John.

I have now confirmed the actual output frequencies with an external oscilloscope.

With REW generating 1,000 Hz:

• 48 kHz: 999.925 Hz
• 96 kHz: 500.060 Hz
• 192 kHz: 249.957 Hz

REW displays no sample rate error.

Since REW checks the rate reported through JAsioHost, could we determine what value JAsioHost actually returns when 192 kHz is selected?

This might help isolate the issue between JAsioHost and ASIO401.

 

[John Mulcahy]

REW sets the driver sample rate when it is changed in REW, reloads the driver, sets the sample rate again after reloading the driver (that was added after the FlexASIO issue you mentioned) and then checks that the driver rate reported by getSampleRate matches the requested rate. Perhaps the 401 driver ignores the setSampleRate calls, or perhaps reselecting the driver causes some sort of reversion to defaults? The code has worked without issue on a range of ASIO drivers including those from Steinberg.

 

[stef1777]

I repeated the test and confirmed the issue is reproducible.

• Start REW with 192 kHz already selected: a 1 kHz sine measures 250 Hz on the oscilloscope.
• Stop the generator, select 48 kHz, then 192 kHz, and restart the generator: the oscilloscope measures 1,000 Hz.

The ASIO401 log confirms that the problematic session streams at 48 kHz without a setSampleRate() call.

ASIO401Test streams correctly at 192 kHz independently of REW.

 

[John Mulcahy]

Meaning it works correctly when rates are changed, but not on startup if the REW rate differs from the device rate? If so, I can fix that.

 

[stef1777]

Yes, that's exactly what's happening. Switching from 48 kHz back to 192 kHz fixes it.

We've also noticed a separate SNR issue, which I'll cover in another thread.

Thanks for your help, John!