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.