add some more:
- I disabled on baord audio chip so should be no driver or devide conflict as ADI-2 is the only audio device in the system
- I don't run high loading tasks in system when listening to music, browse webpage via Chrome and chat with friends with chat app (no any audio usage when met the skipping issue) are mostly used.  i7 8700+32G DDR4 should be enough to cover those tasks.

hi, thank you for replying my post!

Motherboard is ASUS PRIME B360-PLUS. 
I used on board USB port instead of PC front panel audio jack or anything beyond mainboard original port.

here's the test result (surry i have no image server yet)
- 1st one for system without any playback, everything silent. 
- 2nd one for foobar playing normal flac via ASIO output.

Test 1 without any playback
_________________________________________________________________________________________________________
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:00:20  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
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):   268.50
Average measured interrupt to process latency (µs):   5.364218

Highest measured interrupt to DPC latency (µs):       223.30
Average measured interrupt to DPC latency (µs):       1.836715

_________________________________________________________________________________________________________
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):              299.332707
Driver with highest ISR routine execution time:       dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

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

Total time spent in ISRs (%)                          0.060009

ISR count (execution time <250 µs):                   3248
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-999 µs):                1
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):              318.813283
Driver with highest DPC routine execution time:       nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 451.67 , NVIDIA Corporation

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

Total time spent in DPCs (%)                          0.089869

DPC count (execution time <250 µs):                   48016
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                4
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.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count:                 msmpeng.exe

Total number of hard pagefaults                       2
Hard pagefault count of hardest hit process:          2
Number of processes hit:                              1

Test 2 with playback on

_________________________________________________________________________________________________________
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:00:36  (h:mm:ss) on all processors.
_________________________________________________________________________________________________________
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):   916.10
Average measured interrupt to process latency (µs):   3.938565

Highest measured interrupt to DPC latency (µs):       913.80
Average measured interrupt to DPC latency (µs):       1.357219
_______________________________________________________________________________________
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):              184.984336
Driver with highest ISR routine execution time:       dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

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

Total time spent in ISRs (%)                          0.031666

ISR count (execution time <250 µs):                   12435
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):              958.778822
Driver with highest DPC routine execution time:       nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 451.67 , NVIDIA Corporation

Highest reported total DPC routine time (%):          0.061795
Driver with highest DPC total execution time:         Wdf01000.sys - 内核模式驱动程序框架运行时, Microsoft Corporation

Total time spent in DPCs (%)                          0.103239

DPC count (execution time <250 µs):                   81968
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                20
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.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count:                 dllhost.exe

Total number of hard pagefaults                       83
Hard pagefault count of hardest hit process:          73
Number of processes hit:                              4

Oh sure here's the setup for buffer size and sample rate I set:

ASIO Latency buffer size:
- DSD or high bite rate PCM:        8192 samples  (seems to be automatically up to this one)
- normal PCM (up to CD rip):        2048 sample  (the setup i put as default)

sample rate:
- DSD or high bite rate PCM:        176400 or 192000 hz  (seems to be automatically up to this one)
- normal PCM (up to CD rip):        44100 hz  (the setup i put as default)

Usually I set the buffer size to largest as I can, and I can see the buffer size will automatically change depend on the bit rate of the playback. (is that good or bad if changes automatically?)

Sample rate, I just leave it to default and looks it will change by itself as same as buffer size.

Is that a better idea to have onboard soundchip to cover brower and system sounds? That will req separate cables to my speaker and also I got a bit worried whether it will conflict with ADI-2 DAC.

If i want to use ADI-2 DAC to cover all sounds in the system, does that mean I have to suffer this issue since any system sound or brower generated sound will interupt ASIO output and bring a skipping/crack?

Thank you

OK here're the snapshot of Setting page (is that?)

the buffer size and sample rate do variate when system playback different bit rate medias

The one at playback after 1 hour

idle statues

page2, just keep as default

Hi, I turned onboard audio as default playback device and re-install ADI-2 driver, looks the situation looks no improve no matter onboard chip selected as default or not:

Pic 1, I played FLAC in Foobar (ASIO) and the sample rate looks normal, but still got several skippings

Pic 2, latencyMon test result with some time chrowing with Chrome and system panels.  The on board audion was selected as default during the test.

Pic 3, Sounds panel setup with onboard one selected as default device

Is there any suggestion for that?

record high tonight

I was getting random blue screen of death in Windows 10 that turned out to be somehow related to my Razor mouse. After I switched to using another mouse brand (and uninstalled all Razor software) I have not had any more issues with my ADI-2 PRO FS (I still don't know if Razor had conflicts with ADI software or something else - don't care at this point).

There is nothing to fix on our side. You need to fix your computer. This forum has enough threads on how to analyze and solve those problems. Even this thread shows some ideas. If you have latency issues or USB errors the ADI-2 is out of the equation.

Thanks for posting that - You're doing well having resolved it in only 3 hours.  I've been trying to figure out the USB micro stutters that interrupt sound for 6 months.  Lovely little device, but I'm really at wits end and feel like throwing it out the window.

Same problem as everyone else, random 0.5 second skips every few minutes. Brand-new ADI-2 PRO FS R, using J-River. Skipped regardless of WASAPI or ASIO and regardless of any buffering settings. Firmware updated. $200 USB cable, $350 dedicated PCI USB card, $2000 gaming PC, doing nothing more than browsing the web in the background. Tried maybe five other DACs in the past year that had zero problems with skipping, some very cheap, some more expensive than the RME, with the same hardware and everything else.

Uninstalling the RME ASIO driver completely seems to have fixed the problem so far, but that's a bit unfortunate. If I actually did any pro audio stuff and not just listened to music, it would be somewhat fatal. As it is, I can live with WASAPI, it should be bit-perfect playback anyways. If it crops up again over the weekend the unit is going to back for a refund, which would suck, because I love everything else about the ADI-2 PRO and really need the +24 dBu XLR output to help out my amp. But there are other options, even if they do have fewer features (for example, Benchmark DAC3). Hopefully RME can improve their driver reliability. (Again, why should five other DACs I've tried, many with their own ASIO drivers, have worked perfectly?)

So after more hours of listening on WASAPI with the RME driver uninstalled, there are no skips, whereas with the driver, it skipped on ASIO and WASAPI regardless of buffer/sample size. I've tried a good number of the techniques above. At this point I'm fine with sticking with WASAPI and the Microsoft driver. The fewer third-party drivers I have on my system the better, I read articles every day about security exploits in this or that driver. If I ever find real need for ASIO I will revisit the issue. But again there is a clear difference in the stability of this driver vs. the ASIO drivers for other DACs I own in precisely the same hardware and software chain. Maybe that's intentional for some sort of "pro audio" reason, I don't know. For now I'm just going to enjoy listening, I have no arguments with the SQ or functionality.

Hi Stereolab42 - I'd like to try your approach but am new to a lot of this so would you be able to assist?
I've uninstalled the RME driver but then for my PC - Windows 10 64bit Pro - the RME device vanishes.  You talk about listening on WASAPI - is this a different driver I need to install - if so can you let me know where I'd get this from?

Like many others on here, I love the RME DAC - but this little glitch is driving me nuts.  Any help would be greatly appreciated.

Thanks MC - I think I was having other issues on PC also.  Followed instructions and got this working.  I must admit I hadn't quite got to chapter 20 in the manual yet so appreciate your support.  I'll make sure I read the rest.  Great device by the way - a significant upgrade for me.

Hi Kerussm,

This was affecting my system with an old X99 Motherboard (there are some other posts referencing X99 / USB issues ).  Resolved by doing two things:
1. Turn ON pointer trails in Mouse settings (and set them to shortest trail so not seen)
2. Turn OFF XHCI and EHCI handoff in bios power settings.