To the point that you didn't have any problems earlier. Back then, you also didn't have a recording interface with 188 channels. Whether you use only a few channels or not, all channels are always transmitted. These are much higher bandwidths/data volumes that your PC must process in a timely manner.
EDIT: what you do not know is that bad drivers can block CPU cores for too long (DPC latency). Windows and also macOS are no real-time operating systems. To guarantee data integrity, drivers have the highest priority on the system and may not be interrupted by the process scheduler. Instead of this, the time that such a driver stays active on (and blocks) a CPU core is only based on "programming conventions". Only the driver itself can detach himself from the CPU in a timely manner.
If the driver is written bad or "steals" CPU time a little longer (maybe to be better in benchmarks) then it is bad if an audio related job has been scheduled to such a CPU core with high DPC latency. Then the I/O of audio data can not happen in time and you get audio drops. This can usually be mitigated by choosing larger ASIO buffer sizes so that the CPU can work more efficient on the I/O of audio data. But if your system has high DPC latencies, then it is simply not agile enough to process audio data in time.
The situation becomes worse on older systems and if you have only a few CPU cores.
In short: If you see bad LatencyMon figures, then this can be due to bad drivers or bad settings in BIOS/Windows or a combination of both.
Additionally, older USB3 chipsets, especially, were not always 100% compliant with the USB standard. USB2 transfer modes didn't have these problems. But these are all speculations. You should now consistently work on getting the DPC latencies under control.
So, in the BIOS, check if C-States (possibly also T- and P-States depending on the BIOS) and C1N are disabled. After each change, it's best to measure with LatencyMon and log whether the values have improved or worsened.
Turbo and Speed step should remain active. Turbo usually leads to a little higher base clock (around 200 MHz), by Speed step you can control the CPU clock on Windows by energy profiles which is a good thing.
In this blog article you can see what deactivation of energy saving brings approximatly in terms of reduction of latency.
https://www.tonstudio-forum.de/blog/Ent … -X10SRi-F/
After power-saving has been disabled in the BIOS completely, you must then check the settings on Windows.
In Windows, make sure the correct power profile is set, either High Performance or Ultimate Performance (its hidden, google for commands to make the power profile visible and useable to you).
It might also help to reconfigure the process scheduler to "prioritize background tasks" as Microsoft calls it. See https://www.tonstudio-forum.de/blog/Ent … es-or-not/
Behind the scenes, the following happens: this results in an increased time quantum for processes in the process scheduler. Task switches don't happen too quickly for the CPU. This means: fewer context switches for the CPU, more time for the CPU to actually get some work done.
If CRC errors are still visible in the MADIface settings, check if the USB3 cable is not too long or possibly defective. The MADIface settings window must remain open; otherwise, the CRC check will not be performed. Pay attention when reading, as there are CRC5, CRC16, CRC32 checks, and the numbers 5, 16, 32 in this designation are not counters.
Because there is a lot to consider, I have recommended consulting a technician who could assist you. I also mentioned the point that, for these reasons, it is best to get a turnkey system so that you don't have to put in so much effort yourself.
For smaller USB2 interfaces, it is usually less critical because there is less data traffic, and USB2 chipsets/transfer modes are known to be stable for almost all chipsets, with few exceptions.
But these are all problems on the computer, the motherboard, or with inserted cards...
Speaking of cards, it may also help to use a Sonnet USB3 card with an FL1100 chipset to isolate the UFX III from the rest of the USB infrastructure. It has always been a good strategy to isolate a recording interface solely behind a USB3 controller.
BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14