Resync Event ASIO issues

[vhr99]

Dear REW Experts,

I am facing a major issue with this error message:
ASIO device has been reset due to resync request from driver.
No matter what I do, I can't work it out.

I am using an Apollo X Quad Interface via Thunderbolt 3 on an Intel NUC 10, Windows 11 PC. The interface is set to internal clock, since when I set it to S/PDIF I can't get access on the inputs.

For the past three years I am working around this error message. When it pops up during a measurement the measurement usually gets discarded and I have to repeat it. Sometimes several times until I luckily and finally sucessfully bypassed a resync event. Another way is to keep the measurements as short as possible (<256k) because that increases the probability of not getting into the resync interval while measuring.

However it is a huge hassle to repeat each second or third measurement and lately I faced a wall that I can't work around.
When trying to calibrate the sound card, each time after the "measure the soundcard" dialog or 'set the levels dialog', just when the measurement dialog should pop up, the resync error modal pops up instead, and the measurement wasn't already even started. This behavior is reproducible, making it impossible to calibrate/measure the sound card.

I then switched to Java Drivers and reselected all inputs. It works in that regard that I don't get a resync modal, however the measurement is distorted like crazy and I get the modal warning that I shouldn't use it to calibrate. The result is also not determined, changing its appearance each time when measuring.
I suppose it's buffer size issues with the Java Drivers that lead to breaks and clips in the data.

The used configuration of the sound card is 512 Buffer Size, 48KHz. However this is standard and works well with all programs incl. DAWs.

I don't know how I can fix this resync dialog. I checked each and every setting of the soundcard hundreds of times within those years and also couldn't find a REW setting which would remove the resync error.

Meanwhile I appeal and plead for help. There were also some other issues in the background:
- For some unkown reason REW is measuring in stereo no matter which single output is selected. In the signal chain after REW there is no mono that could cause this. Especially as in the Generator it works and follows the selected output, but when opening the measure dialog and having the same output selected like in the Generator both speakers play the sweep. I thought about pulling the cables of the other monitor to force the measurement to sweep on only one speaker, but that's also not an ideal solution.
- Furthermore I wanted to calibrate my soundcard using REW for more accurate measurements and read through the online guide and followed the dialog hints of the program, while configuring my interface to the correct line in and out levels. In this process I configured the sound card for loopback compatibility in a way that I cannot use it for anything else anymore until the calibration measurement is done.

I dearly hope there is someone who can help me on this. I thought I can't be possibly the only person on earth using an Apollo X together with REW on Windows but when googling the resync modal message I couldn't find precise information for my case. The modal also includes the hint of "Input and Outputs may need to be reselected", that however is never the case. The outputs have the same names after the resync and are always still correctly selected. Please if you have any idea of what I can do to fix this issue, please help me.

Kind regards, Chris

 

[John Mulcahy]

Java buffers are huge, that won't be the issue there.

Set your ASIO buffer to the largest value it offers and set the default sample rate for the ASIO driver to the same rate you use in REW.

 

[sm52]

My Audient card behaves the same as yours if the buffer is ASIO 512 or less. With a buffer of 1024, measurements occur almost normally. But sometimes messages still appear that the ASIO driver has been reset. Then I click the Reload button on the soundcard tab in REW, and continue. These resets are caused by insufficient speed of the USB ports. I couldn't do anything about it.

 

[vhr99]

Java buffers are huge, that won't be the issue there.

Set your ASIO buffer to the largest value it offers and set the default sample rate for the ASIO driver to the same rate you use in REW.

I tested it with both 1024 and with 2048 buffer size.
When calibrating the soundcard the resync modal still pops up immediately before the real measurement starts.

Sample Rate is identical on both REW and Apollo Control, on 48KHz.
The driver automatically follows REW, if I select 44.1 the interface changes it's sample rate concurrently.

Is there a way to bypass the resync event in REW? Something seems to trigger it always when the measurement dialog should pop up. Before, there is the level setting where the in and out are already accessed. Can that have any influence on the appearence of the resync event?

What else could I try?

Thank you for your help,
Kind Regards,
Chris

 

[John Mulcahy]

The usual cause of the driver issuing a resync is that it detected a buffer underrun. It isn't something that can be ignored. There are Apollo users, and I have an Apollo Solo I bought a few years back to diagnose an issue with the driver and that still works OK on ASIO, so I don't think there is a fundamental issue. However other Windows users have reported ASIO resyncs. It should work fine with the Java WASAPI exclusive drivers (device names that start EXCL), again my Solo works correctly that way so I'd try the EXCL device entries in Java mode. You may need to fiddle about in UAD console to make sure the input isn't being monitored back to the output, that should just mean muting the input in the console.

 

[phofman]

The interface is set to internal clock, since when I set it to S/PDIF I can't get access on the inputs.

Do you feed some SPDIF stream into the interface when set to SPDIF clock? If not, then probably the device is not freewheeling when set the SPDIF clock.

The buffer under/overrun issue seems to affect that specific hardware/driver https://forum.juce.com/t/asio-failure-on-windows-10-thunderbolt-3/37953 . Maybe checking DPC latency would tell more, but quite likely not fixable anyway.

 

[machismo]

I bought Universal Audio Apollo x4 Gen 2, installed the latest version of Windows 11 (25h2) to a new laptop that has a Thunderbolt 5 port.
Installed the latest driver for the UA Apollo x4 too.

Then also REW V5.31.3 with the following settings: Drivers - ASIO, Sample rate - 96khz, ASIO Device - Universal Audio Thunderbolt.

I press measure, the measurement seems to sound fine and I get the measurement, but right after that REW shows a message
"ASIO device has been reset due to:
Resync Request from driver
Inputs and outputs may need to be re-selected."

and then I can just press OK. Any ideas how to get rid of the error message?

 

[John Mulcahy]

Have you tried all the suggestions in this thread?

 

[machismo]

UAD Console (version 1.2.7.764). Settings - Hardware:
Sample rate - 96 khz, Clock source - internal, Buffer size - 2048 (or when less), Digital mirror - off

REW: Drivers - ASIO. ASIO Device - Universal Audio Thunderbolt. Sample rate - 96 khz.

I use TB5 rated cable and it's connected directly to the laptop, without any hub/dock between.

I also noticed that the first measurement always goes completely without any error. And now that I did some more measurements, sometimes some of the later ones actually do fail, meaning I don't get any result, but over 90% of time I do get.

Pressing "Reload" button in REW makes no difference, or closing all measurements when leaving REW open. Only by closing REW completely, I can do the first measurement without an error. Also having UAD Console open or not, makes no difference.
Since I have the license, I also tried having "Multiple inputs" on with two microphones vs just single input, but also that did not make any difference.

I for sure thought I already tried also with the highest 4096 buffer size setting in the UAD Console, but I guess I had not, since when I now put that on, I got no more error!

So what is this phenomena, that even with buffer size 256 I can do measurements equally well as with 2048? Also why does not my top notch hardware seem to help compared to older machines? Why do you think the first measurement does not fail?

If I put 128 or under, then even the first measurements gives an error, that I do understand, it is simply too low...

 

[machismo]

After it started to work, I now proceeded to do some automatic repeated measurements. Those went fine when length of sweep was 256 or over. But when I set the length to 128k, after just few measurements I got the same "Asio Device Reset" error.

And then, after about 2 second delay without me touching anything, came a new error on top of the previous one, with a red exclamation mark: "No soundcard input data - The soundcard did not provide any input data from ASIO: Universal Audio Thunderbolt, 1: MIC/LINE/HIZ 1, please check that is connected"

Well of course it is connected, so this is something else. So I guess even with 4096 setting, it does not work in all situations?

I then turned off the repeated measurements and did a series of single measurements manually, with the 128k sweep and turns out many of them fail also, with the Asio Device Reset error, but without the second error. I then tried, to see what happens, changing from console the "Input Delay Compensation" values from "short" to "medium" to "long" but that made no difference.

I then did some single measurements still with 128k and just to test, changed the buffer to 1024, after which it give the error every single time. With 2048, error came 80% of the time.
So yes it is clear that the 128k is the most demanding setting. With 128k also the first measurement usually gives the error.

 

[John Mulcahy]

I would guess that the driver doesn't like the frequent starting and stopping of the stream. You can also try the WASAPI exclusive driver, that may be more consistent (Java driver, device name starting EXCL).

 

[machismo]

There is yes "EXCL: Speakers (Universal Audio Thunderbolt WDM)" output, but then I choose that one, I get this:

"Output device error: Unable to access the selected device due to
EXCL: Speakers (Universal Audio Thunderbolt WDM) does not have any lines supporting PCM_SIGNED 96000.0 Hz, 32 bit, stereo, 8 bytes/frame, little-indian
Try a different sample rate. Check that the sample rate of the default format in the Windows audio properties for the device matches the REW sample rate."

Same kind of "Input device error" comes if I choose the EXCL mic input.

If I choose the normal "Speakers (Universal Audio Thunderbolt WDM)" then there is no error but of course I guess that is not bit perfect.

I then uninstaller REW, uninstalled the UA drivers, installed the drivers back and installed REW back, but that made no difference.

 

[John Mulcahy]

Perhaps another application is using the interface or it doesn't have exclusive access enabled in the Windows audio properties.

 

[phofman]

That device is described as 12 x 18 audio interface. If it really supports 12 input and 18 output channels and not fewer, then the wasapi-excl plugin would not check for 18 output channels https://github.com/pavhofman/csjsou...e/sound/provider/SimpleMixerProvider.java#L36

 

[sm52]

series of single measurements manually, with the 128k sweep

I can never take measurements at 128k. Java drivers are slower than ASIO. Or this is how the operating system works with Java drivers. Check the input and output channels after switching from ASIO to Java, and vice versa. Automatically, they can be different.

 

[machismo]

I can never take measurements at 128k. Java drivers are slower than ASIO. Or this is how the operating system works with Java drivers. Check the input and output channels after switching from ASIO to Java, and vice versa. Automatically, they can be different.

If we take or do not take measurements at 128k is hardly relevant here, but providing enough info to find the cause of the problem is. For us regular users, it's impossible to know which bit of info makes the difference.

And now that I took more measurements, turns out that sometimes even with longer 512, 1M, 2M and 4M sweeps I sometimes get the same error too, while buffer is set at the maximum (4096). For some reason, 256 works clearly the best.

To compare further, I took also measurement with using the regular Java - Speakers (Universal Audio Thunderbolt WDM) and while it sounded normal to my ears, I got occasionally "high distortion" error and impulse response of the measurement looked always totally different and messy, it had many peaks etc. So I guess that will not work, I will have to use the ASIO.

 

[machismo]

That device is described as 12 x 18 audio interface. If it really supports 12 input and 18 output channels and not fewer, then the wasapi-excl plugin would not check for 18 output channels https://github.com/pavhofman/csjsou...e/sound/provider/SimpleMixerProvider.java#L36

When I go to I/O matrix, the smallest matrix I can choose is 8 inputs and 8 outputs. However I can leave any of them empty, and then they show as "offline".

 

[machismo]

Perhaps another application is using the interface or it doesn't have exclusive access enabled in the Windows audio properties.

I don't have any other applications open, and I reboot frequently, but I did have the exclusive access not enabled, since somewhere in the UA documentation they for some reason recommended doing so.

I now enabled "Allow application to take exclusive control of this device" and "Give exclusive mode applications priority" As a result, approximately 70% of the remaining errors no longer occurred!

 

[sm52]

I now enabled "Allow application to take exclusive control of this device" and "Give exclusive mode applications priority" As a result, approximately 70% of the remaining errors no longer occurred!

Now try leaving on only those in the recording and playback devices of the system that are needed for REW, for measurements. Disable the rest.