I was able to resolve the issue for the most part. This interface is a little more sensitive to heavy CPU use than my other interface for some reason but bypassing some of the plugins let me record with 64 samples which is fine. I was getting output from my DAW just fine but it was crackling pretty bad.

I will say the preamps and conversion on this sound great though and the latency with using analog gear is really good.

@darenwalker5150:
You could measure DPC Latency to check whether your systems respond fast enough to a DAW load.

You should ensure, that you disabled energy saving on your system, which reduces DPC latency.
a) in the BIOS: by disabling C-/P-/T-States, C1E and enabling TURBO and EIST is useful to control the CPU clock by Windows
b) on Windows by
- using the energy profile High or Ultimate Performance (needs to be enabled, use Google for the powercfg command)
- check, that CPU core parking is disabled, you can check the energy profile by using Bitsum's parkcontrol utility

This table gives you an idea what CPU related latencies you avoid by disabling energy saving in the BIOS (C-States and alike):

Without energy saving you get lower DPC latencies and as a result of this, your system can react more agile to a DAW load.
LatencyMon also supports you well to check which drivers use most CPU time (see tab drivers, highest execution time).

It might still be the case, that you are limited by your CPUs single- and multi-thread performance.
In that regard, it could also be worth checking your DAW projects:
- avoid putting too many VST into one track as insert, this has to run on one thread of your CPU
- if you use CPU hungry VSTi (instruments) take care to freeze the track which creates a wav file for the track saving CPU cycles
- if you are using reverbs, use it as send effect
- avoid CPU hungry VST when recording

You could also export the tracks with VSTi or all tracks forming the "backing track" and import it as wave file so that you have fewer performance demands when recording to the backing track.

Regarding USB...

You mentioned USB3 … the UFX II uses USB2. Each USB3 port is fully backward compatible to USB2.
If you look at an USB3 pinout, the pins for USB2 and USB3 are completely separate.
There are no USB1 controllers any more, USB2 is simply backward compatible to USB1.

You should try every USB port (USB3 and USB2 ports) on your machine, to check whether the drops vanish on a certain port.

When keeping the driver settings window open then a CRC check runs, there you can check if you have any USB transport errors which also could be a reason for audio drops.

In some cases, a good strategy is, to buy a separate USB3 PCIe card to isolate the recording interface behind it.
I would buy a Sonnet card with FL1100 USB3 controller just. Reason: just in case that you would upgrade to an UFX III recording interface in the future. RME tested a few USB3 controllers and the FL1100 is known to run well. Another nice thing is, that the FL1100 (as some other) uses more efficient MSI interrupts and Windows 10 has a suitable driver for it.

Regarding tuning tips for PC or LatencyMon there are many useful postings in this forum, check it out.
Using the extended search you can search for my name and also for the keywords: LatencyMon, powermizer, OS, real-time
https://forum.rme-audio.de/viewtopic.ph … 94#p185494
https://forum.rme-audio.de/viewtopic.ph … 23#p164223

The essence of it, "Why are low DPCs so crucial for a good working system?"

All systems (no matter whether Windows or Apple) are not real-time operating systems.
For data integrity reasons, drivers are not under the control of the process scheduler.
It is hard-coded in the driver, how long they run and when the (I/O) job is finished, they detach themselves from a CPU core.
There are drivers where the developers violated programming conventions, how long it may be active on a CPU core.
If an audio related job with real-time demands has been scheduled by the Operating Systems job scheduler to run on a CPU core, where such a bad driver is running (for too long) then the likeliness for audio drops is high.
It is even higher when working with small ASIO buffer sizes because then the CPU has more load (also interrupt load) and can only process smaller chunks of audio data. Comparable to emptying a bathtub with a thimble instead of a bucket.
Higher ASIO buffer sizes can mitigate or even solve the effect of bad drivers (High DPC latencies) up to a certain point (DAW load).

In other words, if you can solve the issue with high DPC latencies, then your CPU cores can work more agile on different tasks, driver, and user code.
And this you do by
- enabling only hardware in the BIOS that you need
- using good drivers
- disabling power saving in the BIOS and on Windows
- disabling CPU core parking
- using BIOS/Windows settings to get a stable CPU clock without too many rapid changes
In Ultimate Performance mode, no CPU cores are being parked, and all cores run at base frequency plus 200 MHz by having TURBO enabled in the BIOS.