You need to find out what is disturbing audio on your pc.

Look for cpmparison: even with playback of 400 tracks, 800 VSTs at 44.1 up to 96 kHz with only 32 samples ASIO buffer no audio drops.

http://www.tonstudio-forum.de/blog/inde … cks-de-en/

Sorry, but your comparison of old and new recording interface is somehow invalid because the UFX+ has many more audio channels to transport even if they are not in use by your project.
For this reason a problem on PC side was most likely hidden, simply because your old interface had only a few channels.

Did you disable C- / P- / T- States in your BIOS ?
If you can't disable C States set them to C0/C1.

What does LatencyMon report on an idle system when measuring kernel latency timer ?

> Your suggestion about tweaking
> the bios didn’t come up.

RME tech realized earlier than me that you have a Laptop. Am on travel and only have smartphone with me where typing is uncomfortably.

Notebook BIOS have usually less to tweak esp in the area of energy saving.... Some Laptops can also be very weak in terms of audio processing.

Didn't MC tell on forum some weeks/months ago that he also has a Dell XPS Laptop which is kind of challenging for audio? I do not remember whether this was more USB or Thunderbolt related.

Maybe try Process Lasso Pro.
With this software you can bind processes like DAW to CPU cores and Hyperthreading Cores.
You could try to dedicate maybe 50-75% of cores/threads to the DAW process and also increase its runtime and i/o priority.
Then also try Bitsum's High Performance energy profile which disables CPU core parking.

For me PL helped the same way for a game to be able to utilize a brand new GPU RTX 2070 Super. By this the game is now able to 100% utilize the GPU and to achieve higher Frame rates.

For the DAW application the exclusive pinning to CPU cores and slightly higher prio on processes and i/o could result in more ensured processing power for DAW and maybe even less context switches for the CPU cores processing audio.

While talking about context switches... How are your Windows settings ? Did you configure it for priotizing background tasks ? That's important to do, because then the time slices for executing a process become a) static and b) longer. Instead of around 30-70 microseconds runtime around 100. Then the CPU can work more efficient on each process and thread and context switches do not happen so frequent which is kind of expensive (time consuming) for a cpu.

Another idea: use an USB2 cable / port. According to the manual this limits the amount of channels to 30 in and out. So to say all but MADI. This could also help to reduce the audio load and retry every USB port.
Not 100% sure at the moment whether you need for this simply an usb2 cable or an USB3 cable but connected to a pure usb2 port on Laptop.

BTW do you see errors in the usb diagnosis in the RME settings dialog ? You need to keep this window open for the crc check to become and stay active.

With USB3 your cable should be at max 3m long. With Lindy 3-times shielded premium cable even 5m are possible.

Ive redone the latency test...
Although it cannot be compared directly to the first, because this time ive also disabled the wifi AND
the real time scanning of my anti virus........ hum.
Anyways, results are ok now I guess ? See below:

_________________________________________________________________________________________________________
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:02:02  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-GC47NPJ
OS version:                                           Windows 10 , 10.0, version 1903, build: 18362 (x64)
Hardware:                                             XPS 15 9570, Dell Inc., 07GHH0
CPU:                                                  GenuineIntel Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Logical processors:                                   12
Processor groups:                                     1
RAM:                                                  32531 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   2904 MHz

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):   620.60
Average measured interrupt to process latency (µs):   4.645133

Highest measured interrupt to DPC latency (µs):       618.90
Average measured interrupt to DPC latency (µs):       2.311315

_________________________________________________________________________________________________________
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):              416.733471
Driver with highest ISR routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total ISR routine time (%):          0.002381
Driver with highest ISR total time:                   ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in ISRs (%)                          0.002384

ISR count (execution time <250 µs):                   423
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-999 µs):                3
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):              603.595386
Driver with highest DPC routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total DPC routine time (%):          0.004273
Driver with highest DPC total execution time:         rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp.

Total time spent in DPCs (%)                          0.013396

DPC count (execution time <250 µs):                   148605
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                38
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:                 wmiprvse.exe

Total number of hard pagefaults                       659
Hard pagefault count of hardest hit process:          468
Number of processes hit:                              7

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       1.252147
CPU 0 ISR highest execution time (µs):                416.733471
CPU 0 ISR total execution time (s):                   0.034906
CPU 0 ISR count:                                      426
CPU 0 DPC highest execution time (µs):                603.595386
CPU 0 DPC total execution time (s):                   0.185064
CPU 0 DPC count:                                      142070
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       0.504823
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):                7.597107
CPU 1 DPC total execution time (s):                   0.000104
CPU 1 DPC count:                                      85
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       0.482696
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):                17.851584
CPU 2 DPC total execution time (s):                   0.000481
CPU 2 DPC count:                                      332
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       0.540963
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):                12.698691
CPU 3 DPC total execution time (s):                   0.001725
CPU 3 DPC count:                                      1111
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       0.536951
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):                24.323691
CPU 4 DPC total execution time (s):                   0.000725
CPU 4 DPC count:                                      425
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       0.543495
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):                16.993802
CPU 5 DPC total execution time (s):                   0.000381
CPU 5 DPC count:                                      176
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       0.423662
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):                227.381543
CPU 6 DPC total execution time (s):                   0.004016
CPU 6 DPC count:                                      2267
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       0.462476
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):                14.936639
CPU 7 DPC total execution time (s):                   0.000084
CPU 7 DPC count:                                      30
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s):                       0.509726
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):                18.678030
CPU 8 DPC total execution time (s):                   0.000483
CPU 8 DPC count:                                      258
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s):                       0.553426
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):                23.372245
CPU 9 DPC total execution time (s):                   0.001629
CPU 9 DPC count:                                      1357
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s):                       0.532083
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):                64.406336
CPU 10 DPC total execution time (s):                   0.000860
CPU 10 DPC count:                                      295
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s):                       0.567740
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):                79.065083
CPU 11 DPC total execution time (s):                   0.000592
CPU 11 DPC count:                                      237
_________________________________________________________________________________________________________

Ok, man you’ve made my day !
This is really literally the first post for help I’ve ever made and I couldn’t be more glad I did, thanks to you.
Ok so, my old entry level sound card Maudio, now processes 5/6 diva vsts at 32 buffer size, this morning during testing I could do 5 MAYBE, at 512....
This can’t confirm the ufx+ will work as it should but it’s a pretty could indication it just might.
If you ever pass by Hong Kong, you get a free drink on me lol

Your blog has shed so much needed light on some crucial aspects of DAW performance, thank you.

I have installed Process Lasso Pro,
it runs as a service
enabled Pro Lasso's BitSum Highest performance plan,
added ableton live with HIGH I/O priority, should I increase to critical ?

" try to dedicate 3c/6t or even 4c/8t to the DAW process"
I am not sure where to adjust this specific setting.

Ok and finally i've redone a base LatencyMon benchmark before activating PL, and one after. Here are the results:

Seems fairly similar, average might be different because of different analysis time.
But maybe LP's effect is noticable when using my DAW under load ?

Thank you, and later I will update you with the results I get using the ufx+.
Slightly anxious !
__________________________________________________________
_______________________________________________
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:02:57  (h:mm:ss) on all processors.

BEFORE !
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-GC47NPJ
OS version:                                           Windows 10 , 10.0, version 1903, build: 18362 (x64)
Hardware:                                             XPS 15 9570, Dell Inc., 07GHH0
CPU:                                                  GenuineIntel Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Logical processors:                                   12
Processor groups:                                     1
RAM:                                                  32531 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   2904 MHz

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):   244.80
Average measured interrupt to process latency (µs):   4.138336

Highest measured interrupt to DPC latency (µs):       240.60
Average measured interrupt to DPC latency (µs):       2.145578

_________________________________________________________________________________________________________
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):              188.814394
Driver with highest ISR routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total ISR routine time (%):          0.000970
Driver with highest ISR total time:                   ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in ISRs (%)                          0.000980

ISR count (execution time <250 µs):                   467
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):              831.876377
Driver with highest DPC routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total DPC routine time (%):          0.001299
Driver with highest DPC total execution time:         ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in DPCs (%)                          0.004095

DPC count (execution time <250 µs):                   20117
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                46
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:                 searchindexer.exe

Total number of hard pagefaults                       8
Hard pagefault count of hardest hit process:          3
Number of processes hit:                              5

AFTER !

_________________________________________________________________________________________________________
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:07:41  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-GC47NPJ
OS version:                                           Windows 10 , 10.0, version 1903, build: 18362 (x64)
Hardware:                                             XPS 15 9570, Dell Inc., 07GHH0
CPU:                                                  GenuineIntel Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Logical processors:                                   12
Processor groups:                                     1
RAM:                                                  32531 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   2904 MHz

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):   250.70
Average measured interrupt to process latency (µs):   2.437902

Highest measured interrupt to DPC latency (µs):       244.80
Average measured interrupt to DPC latency (µs):       1.032781

_________________________________________________________________________________________________________
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):              320.321625
Driver with highest ISR routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total ISR routine time (%):          0.000862
Driver with highest ISR total time:                   ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in ISRs (%)                          0.000864

ISR count (execution time <250 µs):                   528
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):              647.028926
Driver with highest DPC routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total DPC routine time (%):          0.001276
Driver with highest DPC total execution time:         ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in DPCs (%)                          0.005373

DPC count (execution time <250 µs):                   101618
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                98
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:                 microsoft.photos.exe

Total number of hard pagefaults                       10069
Hard pagefault count of hardest hit process:          1797
Number of processes hit:                              27

I actually always disable WiFi (putting it in airplane mode basically, nothing fancier than that) when using my daw. What I did here was disabling the real time scanning of the antivirus software. But let me re-enable it and see if I’m back to the poor initial results, if not, the bios settings did the trick.

--Results (again thats only for the MAudio, ufx+ coming back this afternoon)

the diva soft synths test is OK, same as the previous test done with tweaked bios, (6 heavy) pad patches at 32 samples.
The LatencyMon for that state are worse obviously, although the majority of the improvement in the DAW seems to have remained.

SAME TWEAK BIOS, BUT Wifi and anti virus real time scanning active
_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system seems to be having difficulty handling real-time audio and other tasks. You may experience drop outs, clicks or pops due to buffer underruns. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for  0:02:48  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        DESKTOP-GC47NPJ
OS version:                                           Windows 10 , 10.0, version 1903, build: 18362 (x64)
Hardware:                                             XPS 15 9570, Dell Inc., 07GHH0
CPU:                                                  GenuineIntel Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Logical processors:                                   12
Processor groups:                                     1
RAM:                                                  32531 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   2904 MHz

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):   1020.70
Average measured interrupt to process latency (µs):   4.651160

Highest measured interrupt to DPC latency (µs):       1018.10
Average measured interrupt to DPC latency (µs):       2.543388

_________________________________________________________________________________________________________
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):              426.024449
Driver with highest ISR routine execution time:       ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total ISR routine time (%):          0.007081
Driver with highest ISR total time:                   ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in ISRs (%)                          0.007083

ISR count (execution time <250 µs):                   1391
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-999 µs):                15
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):              692.418044
Driver with highest DPC routine execution time:       ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation

Highest reported total DPC routine time (%):          0.010509
Driver with highest DPC total execution time:         ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in DPCs (%)                          0.032892

DPC count (execution time <250 µs):                   409128
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                240
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:                 none

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

----------------------------------------------
----------------------------------------------

MC, I would also rather have a simple straight forward user friendly solution, because needing such an intricate/involved tuning process means that for the price of the card you also need some serious knowledge about cpus, which to my recollection is not in the listed requirements by rme.
If a top of the line Dell XPS laptop (albeit still for the consumer market) has shitty drivers, then so be it, although for the price paid for this interface I would expect RME to know about this issue ! Bought it 1 year ago.
XPS are not obscure, corner market laptops.
Paid 1 arm and a leg for the ufx+, and I’m troubleshooting this as if it was a 30yo vintage bike. The real sad part, is that at the end of the day I’m not even sure I will be using the full potential of the card. If a tweak here and there makes incremental changes, then where does it stop ?...

I will reset BIOS settings and redo a LatencyMon test, to get some kind of answer. But full disclosure, in between all the tweaks ive uninstalled a bunch of unused (non audio) programs. Not sure if that had anything to do it with...

I found a full thread about XPS 15 have terrible DPC issues etc..
https://www.dell.com/community/XPS/XPS- … 42/page/10

I’m most probably going to switch to Mac.
Can’t believe this.

I was just about to post to ask if a recent mac would be a safer bet and your comment and this thread :
https://www.forum.rme-audio.de/viewtopic.php?id=26881
Makes it seem like chasing a unicorn.
Pro daw builder, ok, they must less rare than unicorns, so I’m going to find one, I’m guessing it has to be found locally ? Or is there any online build you can recommend ?
Thank you for the advice !

I will push on and keep trouble shooting this... very reluctantly to be honest

The reason why is this:

How do I know when I have reached or at least am close to the true potential of the XPS i9 + RME ufx+ combination !?

Joost has kindly sent me some latency figures, https://eur03.safelinks.protection.outl … reserved=0

is the single oblique audio latency measurement enough to benchmark my system, at least roughly ?

Let’s say I can playback 100 tracks (samples, midi, vstis, external audio etc) with 512 without glitches, that is acceptable. But what if the XPSi9/ufx+ could actually do it at 128, or have 200 tracks at 512.

Then I am driving a Ferrari in traffic on a country side road, when I could be on a empty highway. And that doesn’t feel great.

All this sums up to 1 question, what result(s) of what mesure(s) am I aiming for at least roughly ?

I can’t accept the idea of being told, well if it works with your current 100 track projects then you should be good.
IF 100 is in fact the actual limit, then obviously yes, I’m good.

If I’ve purchased an interface that can do 200, and after having exhausted all the possible fixes, I’m at 110. Then I switch hardware.

Didn’t buy a ufx+ to be badly throttled by the laptop.

Thank you for the insight! I’m going to compare “some measure”* of performance with the Maudio and with the ufc+, for various system settings and for various buffer sizes. Post the results later, I’ll also include the rough cpu usage. As long as both of the cards performances are comparable, then the system still has issues.

To get started I need a utility and the measure to well... measure.
Oblique audio for the RTL ? Is there another measurement I could use the doesn’t involve:
“Make the loopback patch*
Next, make a physical patch (with a cable) from your
chosen output to your chosen input. Ideally, the patch would have unity gain. If it’s hard to achieve this with your setup, then err on the side of caution and attenuate the signal path (i.e. don’t add gain)”

Little worried about the unity gain issue.

DPC latency ? With DPC latency checker ?

There should be huge difference, maybe not cpu -wise but “some measure”- wise between
the low end Maudio and high end rme.

Once I know what to measure and how to measure it, I can tune the laptop.

The RTL figures from my blog article show what RTL values the ASIO driver of different RME products report to the DAW.

RME drivers report this latency value very accurately to the DAW (this is btw not the case for all other vendors, so careful when comparing RME with other vendors).

This RTL value is a constant value when comparing it between different systems if you use the same sample rate and ASIO buffersize.

Therefore it can not be used to judge the performance of a system. It simply tells you that RME USB and Firewire drivers work very efficient and are even on par with PCI/PCIe solutions which is very well.

When looking closely at the values it also tells you that RTL is under 10ms even when using ASIO Buffersizes up to 128 samples and not far from that even when using 256 samples. This is important for people playing virtual instruments to be able to record/play them in time. Especially drummers seem to have strong requirements to work with RTL much below 10ms.

If you ask now for benchmarks then this is tricky. The only guys performing comparable DAW benchmarks are from DAWbench. There you will see, that RME offers the best benchmark results.

But .. every system and every DAW project (and also daw program) is different. Your current situation is simply that something on your system is blocking audio, so that you can't use your RME interface at lowest ASIO buffersizes of 32 samples.

The crackling happens because audio related processes on your system have been scheduled by the Windows process scheduler to a CPU core, where the core is still busy with other tasks and when audio is finally being processed it's already too late, because it has not been processed in time.

Especially problematic are badly written driver's that run for too long. Drivers have highest priorities and such "low level routines" can not be stopped by the Operating systems process scheduler because Windows is no realtime Operating system. Drivers only follow programming conventions to detach from a CPU latest after a certain amount of time.

To have an agile audio system that can be run at lowest asio buffersizes you need a system where its components and drivers work fine and do not block audio.
Additionally you can fine tune the BIOS and the operating system too keep all possible lag as low as possible. Also it's a nice virtue to avoid concurrent jobs on the system while working with audio.
All of this tuning adds to have at the end an agile system being able to process audio in time.

But also this has its limits even on the best optimized PC (laptop is different story on top because of heat, it can not be as powerful as a desktop pc): you simply can not expect that every workload can be executed with lowest ASIO buffersizes.

For recording RTL does not matter, simply choose highest ASIO buffersize for highest safety. If you play with a lot of vst or VSTi then try to work with a DAW that can freeze tracks like Cubase, so that not all VSTi need to be computed when recording or mixing.

Maybe for yor project a buffersize of 128 or 256 would be fine and at the end it could even have a lower RTL than your older card at lower ASIO buffersizes as not all drivers are equal efficient.

It's a difficult topic it needs time to recognize all of the dependencies, being able to fine tune the system and to draw good HW purchase decisions.

All that I can tell you is that the RME UFX+ is a phantastic product. There is nothing wrong with it. From what I read over the years one could say that DELL is in many cases not so ideal for recording.

If you want to get rid of all this complexity with PC hardware the best advice is
1. take a desktop if possible for performance reasons and scalability of cpu power
2. buy from a trusted pc specialist for audio

“Maybe they are good and then the UFX has a much harder time pumping many more channels through usb or thunderbolt (did you try pure thunderbolt? does your laptop have that? If yes that is the best option). The UFX does not unburden the cpu! The m=audio might burden the cpu.“

But I’m only testing with vsti, soft synths.
Tried thunderbolt, usb 3, usb 2 mode, had no effect. From what i understood, it obviously changes bandwidth, but not much speed.

I will do plenty of tests and write everything down and will post results here.
Will have a look at daw bench thank you.
And for my Dell system, well, either it will be tuned, or sold, for a new system that i will cherry pick, optimize and keep stable for years as well, hopefully. This is just too much of a hassle.

If windows is not a real time OS, and many people swear by mac, why are some using windows anyway ?

Neither Windows nor Mac OS X or Linux are real-time OS. Therefore  it's important to have hardware with good drivers that do not occupy CPU cores for too long. Low level routines can not be interrupted by the process scheduler.
So also Mac OS has basically the same issues.

Not too long ago Mac OS X's USB stack was severely broken for  around 10 months until Apple took care of it. It was at times ridiculous what lame excuses came from their support until Apple took responsibility. It's not seldom that thing's need to go through the press until Apple becomes more customer oriented and solve issues for which they are responsible.

All customers with USB recording interfaces (not only RME) were affected by this. Mac OS X additionally uses a different driver model compared to Windows. Instead of ASIO they use Core Audio. Core Audio has a slightly higher base latency compared to Window's ASIO. If you look at DAWBENCH results then Windows performs better as DAW host compared to Mac OS X. BUT when I looked at it years ago they compared Win7 with a Mac OS version of that time, maybe they improved meanwhile.

What I want to tell you is that Mac OS X is also not THE solution.

Even worse, the more performant hardware costs even more money (they are expensive enough for commodity hardware) and the more selected hardware (less variety compared to WINTEL market) is also no guarantee for higher quality or performance.

The opposite is sometimes the case. The ultra thin designs can lead to thermal death of the CPU. In another forum somebody told about severe temperature problems and death of Macs during live production where the systems are 10+ hours under heavy load.

In the RME universe you will potentially miss global record which is not available for Mac OS X and you need to use loopback when working with DIGIcheck. This is ie not needed when working with Windows ASIO drivers, it's easier from operational perspective.

If you want to have it easier then get a turnkey system. Ideally desktop for highest performance and CPU scalability or a laptop designed for audio.

A good german manufacturer is Xi machine's from Hamburg. http://xi-machines.com/de/

Ramses, im in the middle of experimenting with different systems settings and just now realized the LatencyMon operation you mentioned earlier I used was not set to Kernel timer latency. Mine is orders of magnitude above those you mentioned !!

Highest measured is 4000 microseconds
The average valued oscillate around 985 microseconds.
Although at the moment Highest DPC is 544 microsec

I’m not sure how to understand, even less tweak the system for lower kernel timer latencies.
Any idea would be much appreciated. Online i see users mostly attempting to minimize their DPC times...
Thank you

I’m about to modify core affinities for Ableton and then (cross my fingers) and launch the DAW with the ufx+!

Please go to this link and look at some numbers (how to upload pics?):
https://drive.google.com/open?id=1chXnd … cbk7Y2Tekk

I've used ableton live to do this, with 5 or 6 tracks, each of them containing an instance of DIVA.
Using DIVA I can reach the cpu limit.
So I have also done a test where I am under that limit using U-he Zebra.

I've written down the presence of audio glitches or not, for various buffer sizes.
I've written down input, output and overall latency values given by ableton.
Cpu usage % is also included.
All was done at 44.1Hz sampling rate.
The system was untouched during the full 'experiment'.

With the current state of my system, MAUDIO handles more than the UFX+ can (see Diva 6 test), unless I am missing something and this very very possible. So please have a look at those excel sheets, you will see that I have rearranged the values not according to buffer size, but according to overall latencies. I am not sure if even with this re-arrangement the
comparaison is valid.

It is not my intention to compare a toyota to an F1 car, nor is it my intention to throw shade at anyone,
I am troubleshooting this as best as I can, trying to understand what is going on.

I believe that the RME, obviously produces a much better sound, although is that enough to explain the advantage of the MAUDIO ?

I have not yet assigned specific cores to ableton, I am hoping that after I have done that,
the RME will surpass my old card in a more obvious manner ! All this is a little bit disconcerting...

Sorry, I am in vacation without pc, somebody other needs to look at excel and graphics..
I do not know diva etc.
But it sounded to me that you perform the measuring with LatencyMon on a loaded system.
This doesn't bring any insight into the important point how inresponsive your system already is when no applications are running.
Or if you perform BIOS tuning.
How can you see compareable differences of kernel latency timer results of xx microseconds   when the system is under load. This is not possible and the values between different people and systems would be not comparable because we all have different PCs, DAWs and projects.
Measuring on an Idle system is compareable and you have the benefit of seeing the basic load / responsiveness of your cpu's to a workload.

What I need to know before commenting is at the 32 m=audio buffer how much of the 14ms latency is input and output latency. In your test only the output latency is relevant, not total. Most of those cheap drivers have low input and high output latencies. If it is 2ms in and 12ms out it would be equal to the 512 setting of the ufx (roughly)m which would make the rme better overall.

Well if we are comparing output latencies, then the test results are even better in favor of the MAUDIO...
I do not understand.
Also, removing access to Core 0 (with high DPC values) has had no effect for latencies in ableton... Sigh...

That that output latencies are lower then input is good news for the m-audio at least for vsti playback (not for audio recording). So I was right but also very wrong lol.
If you bought the ufx for lower latencies, at least on this machine you are not  getting what you want.

Yes very nice synths!

MetalHeadKeys, yes I’ve tried both of the suggestions you mentioned and much much more lol, in terms of latentices MAUDIO always wins,
Bios tweaked or not,
Process Lasso on or not,
half my laptops drivers disabled or not.

Vinark,
I bought the rme ufx+ because I want to commit full time to producing. And coming from amateur level interface wchich is roughly 17 times cheaper, I never even began to consider than the rme would be slower.
It should out perform the Maudio by a large margin in every aspect of an audio interface (except maybe portability...).
But yes at least on my system as you said.
Although I’ve done this comparaison in many many, different configuration of my system and the results are always the same, rme slower.
So now, I don’t mind (much) getting a true pro audio laptop or desktop, but I cannot be confident at all to make the purchase until someone can be certain that it’s actually my system’s fault...
I just remembered I have an even older soundcard, steinberg ur2...
Let’s see

I’ve tried even tuning the cpu, lowering the voltage with Intel xtreme tuning utility.

Ive only used LatencyMon only without load !
Idle meaning, no software running correct ?
All LatencyMon values have been recorded in Idle state then.

I think showcasing that with various different system states, the MAUDIO is ALWAYS SYSTEMATICALLY faster,
is interesting. Maybe there is no issues at all on my system as well or is anyone absolutely certain 100% that there is ?

You have all my specs and actual latency values of 2 cards.

After doing all that, I obviously wanted to test the cards for practical use in ableton.

Ive improved the DPC value as much as i could,
used PL to remove the problematic core, and again, much much more tweaks,
from 11am until now 8pm nonstop.
No improvement i can find anymore
i thought it would enough...

How do I know there is still a lag ??
Because the MAUDIO is faster and shouldnt be ?
DPC at 0.5 ms in latencyMon,
i have no idea but apparently many people over at Dell are happy with this value...