What system and software do you use then?

https://www.forum.rme-audio.de/viewtopic.php?id=27108

https://www.forum.rme-audio.de/viewtopic.php?id=27110

ASIO or not doesn't matter, the combination of (Asus) X99 and NVidia 980/1080 GPU (driver) can cause USB dropouts, maybe it also causes TB dropouts (which is a combined TB/USB3.1 chipset). Please try the mentioned "XHCI handoff disabled" and mouse-trails workaround.

If this doesn't help then also try to disable the NVidia driver (change to Microsoft VGA driver via device-manager), for testing that is.

If USB is fine and only Thunderbolt causes issues then the cause can be somewhere else of course. I'd just use USB 3 then and analyze the TB issue when time allows. Those dedicated TB cards need a GPU connection, so it could still be useful to try disabling the NVidia driver entirely.

Did you measure DPC latencies yet (LatencyMon)? When you do then remove the RME interface first.

In regards to Windows 10

Which exact version of Windows 10 do you have ? 1709 or 1803 ?

I would like to make you aware of, that Win10 (even 2y after its go life!) still had some severe issues,

1- much slower memory management routines compared to Win7 have been fixed in Fall Creators (1709)
2- another severe problem, that can cause audio stalls up to 200ms, might have been fixed by Redstone 4 (1803)

Its not 100% clear at the moment whether RS4 fixed the very nasty second problem.
It still could be the case that these Microsoft related issues cause your problems or are at least part of it.
Because all latencies at the end add up in the system, no matter where they came from.

More information on these topics, see this blog article, where I put all this information together: https://www.tonstudio-forum.de/blog/ind … s-7-EN-DE/

This is not an RME specific problem, it affects all companies writing drivers and applications.

In regards to LatencyMon

It needs some experience to use the tool and interpret its output correctly.
The best would be if you could post the results.
This is also a nice reference shall you make changes and re-measure.
But then you need to perform this in the same way, so that data is comparable:

TEST 1:
1. freshly bootet system and fresh user loging
2. wait approx 5min, until all system services are started including anti virus upgrades and alike
3. run LatencyMon on an IDLE system, no application start, no user activity, don't move the mouse
4. let LatencyMon run for approx 10 min so that the impact of background programs becomes more visible, before you stop it

Then please post:
a) main screen
b) report
c) drivers screen sorted by Highest Execution time

TEST 2: Execute "In Depth Latency Tests"
Keep basic selection "Tight Loop Latency Test at High_Level_IRQL: measure SMIs and CPU stalls."
This test is also very interesting, as CPU stalls are not displayed anymore in the usual LatencyMon test.
Let this also run for 10 minutes and post also this result.
This is very interesting to see what the max CPU stalls are under high interrupt load.

Windows Optimization

Did you optimize Windows 10 for Audio ?
- Disable energy saving entirely in the BIOS (C-/P-/T-States, enable only for C0/C1, disable C1E, disable P-/T-States,
- Use of High Performance Energy profile
- Disabling of CPU Core parking
- Configure process scheduler to Optimize for Background Tasks
- deactivate automatic update services for all applications (do this all manually)
- reduce the number of not required background services / jobs (see windows services and task planner)
- deactivation of all startmenue apps, which still run in the background
- enabling all privacy settings to prevent some of the data transmissions to Microsoft
- deactivate additionally Windows Services related to data collection (telemetry services and alike)
- deactivate Windows Search or parametrize it wisely not to cause too much load,
   by i.e. only collecting based on meta data and certain folders
- disable regular defragmentation jobs
- when installing add-on applications, take care not to install additionally suspicious tools and take care not to enable automatic software upgrades, perform all this manually if not working with DAW ....

If you record and need near-realtime behaviour you need to take care to silence your system to support for optimum performance. Disabling energy saving and reducing the amount of background service activity or startup of programs is the key to success. Maybe by this you can create "savings" that mitigate additionally the things which possibly are still not right in Win10, in regards to these audio stalls up to 200ms.

Here are my LM results:

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for  0:10:10  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-DLM3B3D
OS version:                                           Windows 10 , 10.0, build: 16299 (x64)
Hardware:                                             All Series, ASUS, ASUSTeK COMPUTER INC., X99-A II
CPU:                                                  GenuineIntel Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz
Logical processors:                                   16
Processor groups:                                     1
RAM:                                                  65425 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   3198 MHz
Measured CPU speed:                                   1 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs):   103.740153
Average measured interrupt to process latency (µs):   2.253552

Highest measured interrupt to DPC latency (µs):       102.139224
Average measured interrupt to DPC latency (µs):       0.689906

_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs):              46.939024
Driver with highest ISR routine execution time:       dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%):          0.013284
Driver with highest ISR total time:                   dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Total time spent in ISRs (%)                          0.013345

ISR count (execution time <250 µs):                   86479
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-999 µs):                0
ISR count (execution time 1000-1999 µs):              0
ISR count (execution time 2000-3999 µs):              0
ISR count (execution time >=4000 µs):                 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs):              387.997811
Driver with highest DPC routine execution time:       ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

Highest reported total DPC routine time (%):          0.010486
Driver with highest DPC total execution time:         nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 397.64 , NVIDIA Corporation

Total time spent in DPCs (%)                          0.035603

DPC count (execution time <250 µs):                   2748071
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                15
DPC count (execution time 1000-1999 µs):              0
DPC count (execution time 2000-3999 µs):              0
DPC count (execution time >=4000 µs):                 0

_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

Process with highest pagefault count:                 none

Total number of hard pagefaults                       0
Hard pagefault count of hardest hit process:          0
Highest hard pagefault resolution time (µs):          0.0
Total time spent in hard pagefaults (%):              0.0
Number of processes hit:                              0

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       6.656860
CPU 0 ISR highest execution time (µs):                46.939024
CPU 0 ISR total execution time (s):                   1.302404
CPU 0 ISR count:                                      85843
CPU 0 DPC highest execution time (µs):                116.183240
CPU 0 DPC total execution time (s):                   2.298943
CPU 0 DPC count:                                      1861971
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       2.023916
CPU 1 ISR highest execution time (µs):                0.0
CPU 1 ISR total execution time (s):                   0.0
CPU 1 ISR count:                                      0
CPU 1 DPC highest execution time (µs):                387.997811
CPU 1 DPC total execution time (s):                   0.007146
CPU 1 DPC count:                                      4837
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       2.335993
CPU 2 ISR highest execution time (µs):                0.0
CPU 2 ISR total execution time (s):                   0.0
CPU 2 ISR count:                                      0
CPU 2 DPC highest execution time (µs):                387.547217
CPU 2 DPC total execution time (s):                   0.142097
CPU 2 DPC count:                                      108719
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       2.167631
CPU 3 ISR highest execution time (µs):                0.0
CPU 3 ISR total execution time (s):                   0.0
CPU 3 ISR count:                                      0
CPU 3 DPC highest execution time (µs):                387.321138
CPU 3 DPC total execution time (s):                   0.009510
CPU 3 DPC count:                                      7302
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       2.267991
CPU 4 ISR highest execution time (µs):                0.0
CPU 4 ISR total execution time (s):                   0.0
CPU 4 ISR count:                                      0
CPU 4 DPC highest execution time (µs):                387.419012
CPU 4 DPC total execution time (s):                   0.121306
CPU 4 DPC count:                                      115649
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       2.073242
CPU 5 ISR highest execution time (µs):                0.0
CPU 5 ISR total execution time (s):                   0.0
CPU 5 ISR count:                                      0
CPU 5 DPC highest execution time (µs):                387.190119
CPU 5 DPC total execution time (s):                   0.013382
CPU 5 DPC count:                                      9807
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       2.261988
CPU 6 ISR highest execution time (µs):                0.0
CPU 6 ISR total execution time (s):                   0.0
CPU 6 ISR count:                                      0
CPU 6 DPC highest execution time (µs):                386.884615
CPU 6 DPC total execution time (s):                   0.113952
CPU 6 DPC count:                                      104578
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       2.155419
CPU 7 ISR highest execution time (µs):                0.0
CPU 7 ISR total execution time (s):                   0.0
CPU 7 ISR count:                                      0
CPU 7 DPC highest execution time (µs):                386.699187
CPU 7 DPC total execution time (s):                   0.017955
CPU 7 DPC count:                                      8930
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s):                       2.351926
CPU 8 ISR highest execution time (µs):                0.0
CPU 8 ISR total execution time (s):                   0.0
CPU 8 ISR count:                                      0
CPU 8 DPC highest execution time (µs):                386.558787
CPU 8 DPC total execution time (s):                   0.119212
CPU 8 DPC count:                                      110893
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s):                       2.313326
CPU 9 ISR highest execution time (µs):                0.0
CPU 9 ISR total execution time (s):                   0.0
CPU 9 ISR count:                                      0
CPU 9 DPC highest execution time (µs):                386.382427
CPU 9 DPC total execution time (s):                   0.007409
CPU 9 DPC count:                                      4395
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s):                       2.323984
CPU 10 ISR highest execution time (µs):                0.0
CPU 10 ISR total execution time (s):                   0.0
CPU 10 ISR count:                                      0
CPU 10 DPC highest execution time (µs):                386.043152
CPU 10 DPC total execution time (s):                   0.152786
CPU 10 DPC count:                                      129909
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s):                       2.057173
CPU 11 ISR highest execution time (µs):                0.0
CPU 11 ISR total execution time (s):                   0.0
CPU 11 ISR count:                                      0
CPU 11 DPC highest execution time (µs):                385.881176
CPU 11 DPC total execution time (s):                   0.017375
CPU 11 DPC count:                                      9665
_________________________________________________________________________________________________________
CPU 12 Interrupt cycle time (s):                       2.248907
CPU 12 ISR highest execution time (µs):                0.0
CPU 12 ISR total execution time (s):                   0.0
CPU 12 ISR count:                                      0
CPU 12 DPC highest execution time (µs):                385.585366
CPU 12 DPC total execution time (s):                   0.158460
CPU 12 DPC count:                                      115425
_________________________________________________________________________________________________________
CPU 13 Interrupt cycle time (s):                       2.017770
CPU 13 ISR highest execution time (µs):                1.276110
CPU 13 ISR total execution time (s):                   0.000115
CPU 13 ISR count:                                      636
CPU 13 DPC highest execution time (µs):                385.387742
CPU 13 DPC total execution time (s):                   0.034946
CPU 13 DPC count:                                      15605
_________________________________________________________________________________________________________
CPU 14 Interrupt cycle time (s):                       2.297922
CPU 14 ISR highest execution time (µs):                0.0
CPU 14 ISR total execution time (s):                   0.0
CPU 14 ISR count:                                      0
CPU 14 DPC highest execution time (µs):                385.115072
CPU 14 DPC total execution time (s):                   0.162918
CPU 14 DPC count:                                      117170
_________________________________________________________________________________________________________
CPU 15 Interrupt cycle time (s):                       2.113237
CPU 15 ISR highest execution time (µs):                0.0
CPU 15 ISR total execution time (s):                   0.0
CPU 15 ISR count:                                      0
CPU 15 DPC highest execution time (µs):                384.900876
CPU 15 DPC total execution time (s):                   0.097594
CPU 15 DPC count:                                      23231
______________________________________________________________________________________________________

I don't own a TB based RME interface, so I cannot test this further.

Does it happen when Cubase and the other application use different channels?

Are you using Cubase and Chrome (mixed) over the same audio channels or do you use like channel 1+2 in Cubase and channel 3+4 for Chrome/Windows?

In TEST 1 I see nothing spectacular.

If it doesn't create too much work, could you also kindly provide data from Test2 ? Also for 10 Minutes if possible.

In many cases it is simply a strategy to reduce the likeliness of audio loss even under heavy CPU and/or i/o load.
Or to enable to use smaller ASIO buffers at a given load, as the fine tuning makes the CPU "agile enough"
to process audio related jobs quick enough / in time.

An optimum result is simply the SUM of all tuning effords in different fields:

1) disabling energy saving for CPU cores remove latencies up to more than 250us, as a core needs time for waking up
Tools like LatencyMon i.e. alarm, if there is a latency over 1000us, so you see now the importance alone of of the tuning in the area of energy saving for the CPU ?!

2) disabling CPU cpu core parking removes the latency for CPUs to wake up.
Steinbergs Cubase removes i.e. CPU core parking when you enable the optimized Energy Profile from Steinberg.
They know already the importance. Also gamer know about this, especially to eliminate micro lags in graphics output, especually in multi GPU setups if I remember right

3) disabling not required devices in the BIOS removes the amount of drivers being active in the system and thus the likeliness that an audio process could be blocked by driver execution.

4) certain devices like WiFi, Bluetooth adapters are known to often cause issues, but I think it also depends on the driver and the hardware, how often Interrupts are being generated for such a device. We want to avoid driver to block a CPU core.

And still you can have bad luck to get a combination of mainboard / BIOS, which I had one time, where you can perform fine tuning in the BIOS but still achieve lame results, some HW is simply bad.

In one case a Lenovo Laptop with integrated CPU cause audio drops during simple playback over ASIO driver (MusicBee).
When turning only 1x the mousewheel in firefox you got an audio interruption which went away with ASIO buffer sizes over 256. But this is ridicoulous high for such a low workload.
By occasion I found out that all these issues went away when using the separate dedicated nVidia GPU for Firefox. Luckily this laptop had such an additional GPU.
After that all audio drops were away even when using lowest ASIO buffersize of 48 samples (for the UFX) and even under some more load.

I even wouldnt exclude that maybe there might be an issue with the implementation of TB on your mainboard.
If I remember / understood it right, the BIOS has settings for a particular TB adapter especially for your mainboard.
It sounds to me as if you can't simlpy use a TB card of another vendor or which is for another board.
At least one article that I read sounded this way.
By this I can imaging, that also in this area there can be BIOS errors and alike.
Maybe you should also have a look for BIOS upgrades for your mainboard, which might fix issues in this area.
I would open also a support case at the vendor for your board, whether he has an idea ...

These values all look very well to me. Maybe the mainboard vendor can give you some advice what TB settings might be worth to become tweaked.

Maybe give it some time, there was vacation time and frankfurter music exhibition 2018 and new products came out.

Apologies for that, that was an unfortunate accident... I was on holiday when your mail came in, and when I returned, it was among those marked as replied, when in fact it wasn't... That's why I thought it did not need further attention. Again, sorry for that.
I'll get back to you later today, but I'm not sure I can offer an immediate solution.

Regards
Daniel Fuchs
RME

Thanks Daniel, I've replied to your email so we can take it from there, I'll update here if/when a solution is found.

Thanks for reminding us on this one!

I can confirm that disabling "XHCI handoff" in BIOS and 'enabling mouse-trails' in Windows has had no effect.

Another issue I'm experiencing is random sub 1 sec bursts of white noise.

Support have asked if I can try 'Release driver when application is in background' in Cubase so this is what I'm trying at present. Will report when I have some results.

I hope its not this though as it means that audio cuts out as soon I switch from Cubase to another application.

Did you ever get this working? If not, you may want to try the Startech thunderbolt adapter, as I have noticed that that is the one that it recommends in the user manual:

" The latest computers incorporate a Thunderbolt 3 interface via USB-C connectors.
For these, external adapters are available (for example Star-Tech TBT3TBTADAP)
which convert Thunderbolt 3 to Thunderbolt 2, allowing to connect the UFX+ to any Thunderbolt
3 equipped computer."

The apple one seems to have potential issues on Windows systems, at least with some interfaces.

Matthias Carstens  from RME posted this a while ago in reference to the apple adapter: "Unfortunately, the Apple adapter only works with certain hardware"

If the adapter were the cause here, then this would likely also affect ASIO operation.
Your last mail also said the issue had first appeared to be solved, but then returned, although less frequently. This makes it hard to trace and diagnose, and even harder to provide a simple solution. Does the number of active WDM devices make any difference?
Meanwhile, the lastest driver is this, have you tried it?
https://archiv.rme-audio.de/download/dr … _09673.zip

If USB 3 is not affected here, is that not working solution for the time being?

Regards
Daniel Fuchs
RME

The channel count is NOT reduced with USB 3. USB 3 is fully identical to TB operation. The only difference stems from the fact that on many systems USB is not as stable as PCIe (=TB), so TB might be able to reach a bit lower latency (we are talking about one buffer size smaller), and operates better at very high CPU loads. There are always exception to the rules, of course.

I know this is a late reply, but it is possible that it could be a BIOS setting related to the TB AIC. I am on an Asus Z370-A system with the UFX+, so not exactly the same, but I am using the ThunderboltEX3 card. I remember one time that I accidentally reset my BIOS to default and had to reconfigure the thunderbolt settings. While trying to get the bios settings for thunderbolt fixed, I noticed that Spotify would just crackle when I tried to play something. After messing with the BIOS thunderbolt settings again, the problem vanished. I unfortunately do not remember the specific setting that fixed it, however. It does seem that the BIOS settings for the AIC card can be very finicky though.

sorry to be that guy but i dont see the senario that usb3 and rme usb drivers cant serve you..i mean why pay 40 bucks for Tb cables and more for adapters and pcix cards? is that of a difference between lets say 3-4 ms latency and 6-7 with usb?