The significant difference between ufx+ and the other interface is
- USB3
- much higher channel count ~4 vs 188

Something does not work properly.
Is this a Win10 preinstallation from factory?

Same but with Core 0 included in the LatencyMon test,

_________________________________________________________________________________________________________
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:01:36  (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 DPC LATENCIES
_________________________________________________________________________________________________________
The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution.

Highest measured interrupt to DPC latency (µs):       484.20
Average measured interrupt to DPC latency (µs):       2.631461

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

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

Total time spent in ISRs (%)                          0.001718

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

Highest reported total DPC routine time (%):          0.007773
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.015463

DPC count (execution time <250 µs):                   134076
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                57
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:                 securityhealthservice.exe

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

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       0.933569
CPU 0 ISR highest execution time (µs):                188.600895
CPU 0 ISR total execution time (s):                   0.019789
CPU 0 ISR count:                                      254
CPU 0 DPC highest execution time (µs):                483.184573
CPU 0 DPC total execution time (s):                   0.168672
CPU 0 DPC count:                                      131206
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       0.352964
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):                0.0
CPU 1 DPC total execution time (s):                   0.0
CPU 1 DPC count:                                      0
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       0.385344
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):                16.774793
CPU 2 DPC total execution time (s):                   0.000553
CPU 2 DPC count:                                      192
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       0.382610
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):                6.643251
CPU 3 DPC total execution time (s):                   0.000026
CPU 3 DPC count:                                      15
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       0.377558
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):                11.686639
CPU 4 DPC total execution time (s):                   0.000190
CPU 4 DPC count:                                      79
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       0.382851
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):                0.0
CPU 5 DPC total execution time (s):                   0.0
CPU 5 DPC count:                                      0
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       0.393154
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):                22.608471
CPU 6 DPC total execution time (s):                   0.007555
CPU 6 DPC count:                                      2328
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       0.391922
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):                11.122245
CPU 7 DPC total execution time (s):                   0.000053
CPU 7 DPC count:                                      17
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s):                       0.392791
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.863292
CPU 8 DPC total execution time (s):                   0.000322
CPU 8 DPC count:                                      82
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s):                       0.392742
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):                0.0
CPU 9 DPC total execution time (s):                   0.0
CPU 9 DPC count:                                      0
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s):                       0.362744
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):                17.621212
CPU 10 DPC total execution time (s):                   0.000767
CPU 10 DPC count:                                      214
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s):                       0.378164
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):                0.0
CPU 11 DPC total execution time (s):                   0.0
CPU 11 DPC count:                                      0
_________________________________________________________________________________________________________

Yes, it came pre-installed, but as usual with all my systems, I am careful what is installed on it.
I absolutely removed all that was unnecessary, everything I could think of
I've disabled all possible useless drivers not used for audio.
Uninstalled my anti-virus and stopped windows defender from running.
I was as thorough as i can be.
Removed a lot of background services not needed.
Windows search indexer for example and more..

This is probably as far as I can go..

Although my latest test seems to have improved things a bit,
but again the advantage of the rme is not very obvious.

CPU could be throttling, but then again its also throttling for the maudio.

Reinstalling windows, will probably not help, as others have reported...
I've contacted Process Lasso team to maybe obtain specific tips...

I will now undervolt my cpu for less heat, but trying to make that the cpu tuning software does not interfere with audio processes...

But lets say Reaper gives better results ?
It means Ableton is less optimized but where to I go from there ?

only if it works indeed, keyword IF ! lol

What would be of interest whether the loss of audio is related to the additional high cpu load of the 5-6 VSTi.

What happens if you perform simple music playback of a flac file using foobar2000 or MusicBee using the RME ASIO driver.

If this would be possible now then I would come back to the point that freezing of VSTI tracks like in Cubase could reduce cpu load significantly.

If you say that on dell laptops it's typical that core 0 gets high load. Could it be the case that maybe some audio related processes get in trouble on that particular core?

Assumed your VSTi processes are shown in the process list as threads of Ableton then you could try with process lasso pro to assign the Ableton process (and by this also it's threads) to work ie on core 2-11 or even 2-13 (out of 0-15) . Maybe you can even identify the RME Driver and assign him a cpu core.

You need to look in process lasso pro to make this assignment permanent. Then whenever this process starts then this assignment takes place.

But don't oversubscribe. Leave at least 2 complete cpu's for the other stuff.

Maybe 0+1, 14+15 unassigned.
2-11 for Ableton
12+13 for rme driver

Then eventually on top a little higher process and i/o priority.

The use of another daw is simply to exclude that you see same behaviour or not to be able to exclude Ableton as root cause.
I would choose a demo version of cubase and try freezing of tracks because you will surely not play 6 synthies in parallel ...
I think it's a valid approach of doing this to lower cpu load.

And this then in combinto on with the other tuning tips and by lowering the amount of channels.

Still you didn't answer whether this is a new win 10 installation that you performed or preinstalled from factory which is usually crap based on my experience with other laptop's.  Even Lenovo preinstallations you cannot trust to put an example.

Does the UFX+ have already the latest firmware flashed ?

You will, also, need to clean windows registry!
I use CCleaner for that. There is a free and a paid version. The free version is great!

Hey, Ramses!

I don't mind you, disagreeing!

Yes, a clean install and careful installation of new things is the best way. I've only read good things about CCleaner, though, and from my experience, I have no horror stories to share!

I mainly use it on my laptop for cleaning internet cache, cookies, temp files etc, which I use for internet browsing.
I, also, use it on my desktop pc which is dedicated for audio(and some gaming ). On this pc, of course, I carefully install programs or plugins, but when I want to uninstall anything, I always use CCleaner afterwards to clean the registry. Of course, I observe every registry key that the program states that needs deleting, and I check if it's relevant to the program I uninstalled. So far, no harm done!
I 've, also, used it on many friends' pcs and laptops, for the same purposes and no horror stories from their side, either!
You can have a registry backup file, if needed, as well!

I know what you 're talking about, though, and I was very sceptical before using it, but I did, and it works great for me. I 'm talking only about CCleaner in particular!
The only reason I suggested it to Adrien, is for all these hours of tweaking, to not go wasted. And if he, finally, performs a clean install, he could run CCleaner as a last resort before that!

@all

yes i've tried all the proposed tweaks already, short of formatting.

"unchecked the "Allow computer to turn off this device" option"

"The factory setting for the Interface Mode, Auto, makes sure that any connected   computer   connection   is   recognized   automatically. Thunderbolt,  USB  3,  USB  2  and  Class  Compliant  will  usually  work without  any  further  user  interaction.  In  case  of  problems  the  current interface mode can be set manually to a fixed one. This is done under SETUP/REV, Options, Hardware/Diagnosis, Interface Mode."

I know ccleaner, I used it in the past. And those softwares including ccleaner are a bit controversial..
might do a single quick cleaning though, lets see.

@ramses

downloading now foobar2000.
But this is a comparison test. It means that if I am well under the limit of what the ' Dell/ufx+ OR maudio system '
can do, then both the ufx+ and Maudio will play it easily. 

mmmmh... Not sure if you absorb all of the information I post. sigh

Yes i will use more than 6 synths lol !
But current projects has well above 50 synths ! (mentioned that a few times)
More importantly, the point is NOT to freeze tracks to reduce cpu load, its a well-known method indeed, i agree.

The point is to test the limit of the ufc+/dell (mentioned already) vs maudio/dell.

The point is to optimize the setup I have, Maudio does not need to freeze tracks at all.

If the ufx+ needs tracks frozen then 2 only 2 possible reasons:

A: the Dell system is already quite optimized and 
unfortunately, bizarrely, disappointingly, the ufx+ handles less than the Maudio (FOR THAT SOFT SYNTHS TEST), for some reason. On the other, the sound quality should be better, and other obvious advantages for the rme. But it would still be strange, because i would believe that, everything the maudio can do the rme can do easily AND MORE.

B  : the Dell system is not optimized well enough, so
for the ufx+ to shine and be able to handle for example maybe 6 diva synths at very short rtl, the Dell has to be super fined tuned to the extreme.

Again:
The diva project file is my way of doing my personal little "benchmark" on my Dell.
The diva project test is really heavy - ON PURPOSE - (mentioned already) for the sake of testing and debugging only.

Also mentioned a few times is the fact that i've already configured core affinities with process lasso.
To no effect.

Including i/o, memory.

On that note, here is the reply from the bitsum guys:
"You should not set it to Below Normal or Idle. That snippet was trying to convey that, in your example, *other* apps which could interfere with Ableton should be lowered in priority class, rather than Ableton raised in priority class. ProBalance does this automatically.

While you could raise the priority class of Abelton to High or Real-Time, I would not expect it to improve performance or responsiveness.

In addition to process priority classes, each thread in a process has a priority. Ableton almost certainly sets its important threads to real-time (time-critical) priorities. Further raising the priority class of the entire process just won't achieve any additional effect.

I/O priorities and memory priorities aren't likely to matter either.

All this said, Windows PCs have a complex software and hardware environment, with a lot of variables to account for, so it isn't impossible some tweak that shouldn't matter, actually does.

In the end, I'd just leave Ableton alone, let ProBalance do its job, and limit the number of custom tweaks you make."

Drivers are up to date, everything has been flashed with the latest firmwares (mentioned a few times i believe).

About the windows installation: see previous post.

The reason why I asked you to check, whether simple playback of a flac file at 32 samples ASIO buffersize works, is to see whether audio playback at that buffersize basically works.

To have a basement to say ok this works.

I think  that your Dell might be capable to exchange audio data with your UFX+ reliably up to a certain cpu load of the system (as too high DPC latency let the process time for other processes shrink. After a certain cpu load this is not guaranteed anymore with small buffersize's.

Your 5 synthesizer or your personal diva stress test does not work anymore with a 188 channel interface ON THIS Laptop. I would say good-bye to your old stress testing of an interface because this test generates too much cpu load that for 188 channels it's not possible any more to perform the i/o in time and especially not at smaller ASIO buffersizes.

It would make more sense now to look how to work with your UFX+ in the best possible way.

So pls do not try stress tests that won't bring you any further, use a real project.
In this project try to bring CPU load down to a level that your laptop is still able to exchange audio data in time.
This you can do by freezing tracks with VSTi''s and using a reasonable ASIO buffersize.

In some of my projects I could also not use asio buffersizes of 48 or 32 simply because the masterIng plugin generated too much load.
I had to use 512 samples buffersize.

Another reason for this was my workflow. For me as non commercially working hobbyist I saw no merit to make a clear cut between mixing and mastering.

So when doing mastering there were still all the VSTI running. But for me no problem because if you reached the mastering stage then RTL does not matter at all, there I do not record with VSTI anymore. So there I can also choose 512, 1024 without any issue's.

My advice to you is not to fight windmills by thinking you need to be able to run the same load tests with a 188 channel interface like before with a 4 channel interface.

The UFX+ has excellent RTL at any ASIO buffersizes. You need now to learn how to organizIng your projects in a way that it works reliably.

The recording interface is nothing which accelerates your computer in any way. It's not like a coprocessor card. It's only more efficient working compared to consumer cards and Windows drivers. Otherwise it's simply deman ding to your computer to perform i/o operations in time.

Baseball I would keep also the 32 channel setting as long as you do not need madi extensions.

Or you simply need another laptop or desktop which can deliver better.

If I am nor wrong there is a certain tendency that Dell is known to have issues with dpc.
And it's genearly hard to find good laptops for audio. Either use selected ones for audo or better desto.  But evendor with desktops there are pitfalls.

Otherwise good luck with new installation.
Make photos of which driver and programs are installed and try to leave out as much as possible from Dell add on tools / programs or also drivers as possible.

Sorry for problems in communication typing with smartphone is he'll in such a long thread with many tools output.

Or you could even get the Digiface USB and hook up your ADI 2 Pro Fs via optical SPDIF for monitoring purposes, if you don't need external preamps! I use it and it's great!

And please update us with the Mac Test!

Oh and will update shortly about the flac test, yes it’s a good base.
Although I’ve already played back 1 audio sample on 1 track in ableton and at 32 it’s hard.. 64 was ok.

@Adrien

Another thing to try before a clean install!

Some years ago, a friend of mine who run a studio, could not have a usb stick identified on his pc. I researched for a few days and finally found that the problem was that windows had a limit of 100(I think) usb drivers.
The reason was that, by having a studio, he was constantly connecting/disconnecting usb sticks of various customers. And windows would install the same driver for as many different ports, he would connect each one to. This is how I fixed it:
https://www.maketecheasier.com/remove-o … s-windows/

Perhaps, there are old usb drivers in your laptop, creating conflicts. Well, that's the last thing I can think of, to be ruled out, since we covered everything!

@ Ramses !
No ! Again no !
I mentioned my current project file (song) a few times as well. This is not purely academic.
And freezing tracks can make a difference in workflow, as it really depends on the person’s initial workflow...

Metalhead, ok, will check the usb tweak

Thanks for the clarification. While we use the same chipset, CPU and graphics cards are different. As is the BIOS etc. Indeed the 9570 has a bad reputation when it comes to DPC and audio, moreso under heavy load as it tends to clock down the CPU early.

I gave you this recommendation already very early in this thread: https://forum.rme-audio.de/viewtopic.ph … 91#p148391

I did some research on this topic last recently. This is my summary what it does: https://www.tonstudio-forum.de/blog/ind … es-or-not/
"background process” priority tweak is a complete misnomer for this setting.

The source of information that I found on this topic came to other conclusions than the forum colleague from Xi on gearsluts who claims it reduces performance: http://recoverymonkey.org/2007/08/17/pr … unixlinux/

But anyway, what we want to achive with this change is not primarily "higher performance" we want to achieve stability for audio that the CPU can work more efficiently on processes and threads and does not have too many process overhead by switching the context too early and thus too often. I can not really think of that performance should be affected in a negative way by a CPU which can work more effiently with less context switch overhead.

"The longer, fixed quantum of Windows Server means less system resources are wasted on context switching and all processes have the same quantum. With such a scheme, more overall system throughput can be realized, and it is more of a "fair scheduler" for all processes. It also explains the higher benchmark numbers when the scheduler is run in "background services" mode. It's obviously best for systems that run a few intensive processes that can benefit from the longer quantum (and believe it or not, games and pro-audio applications run better that way)."

This is BTW not a RME specific workaround, this is a general audio tuning recommendation which exists since a very long time (> 15 years). Nearly every tuning guide lists it.

My answer to this topic on gearsluts thread: https://www.gearspace.com/board/showpos … tcount=126

I like MC's idea to really check whether the Laptop has latest DELL BIOS deployed and to check whether the latest drivers are deployed (where the latest is not always the greatest).

After thinking a while about this thread .. I hope of course, that the sum of all proposed tuning measures finally
will lead to satisfactory results.

But I have a certain feeling that Adrian did not plan his system careful enough for his special requirements,
that the system needs to work without audio loss under
a) low ASIO buffer sizes and
b) when using his personal "stress test project"
and considering that a 188 channel recording interface is more demanding for a system.

The real big problem here appears to me is, that the DELL laptop is not the best choice for these requirements.
Its maybe also a bad understanding of Adrian, that a RME recording interface can compensate a bad HW choice fully.
And especially tricky because the UFX+ has so many channels which creates higher audio bandwidth / processing demands.

I think in a good case of luck he gets it going up to a certain point, but I fear comprimises are to be made, like
freezing of tracks or to choose wisely which ASIO buffersize to use depending on the CPU load of the project,
number of VSTi/VST, whether they are esp CPU consuming, etc.

The drivers of the DELL might take too much CPU time, there is not so much left to process audio processes in time
and especially not for a higher number of channels (defenitively more than 4, either 64 or 188).

Good luck with the further new setup of the system and to check for latest BIOS, maybe better driver or maybe also involving DELL. I hope for you that the tests with Apple or another Windows system are more positive for you.

But as you can see now, how many work bady chosen HW can cause, you understand maybe better,
why where are still companies on the market who can survive on the market by selling turnkey systems.

Its simply a very time consuming work that also requires a lot of experience in the area of system tuning and it needs background knowledge on how computers work. This is not so easy if you operate a system from end user perspective.

Much easier would have been for your type of requirements to talk to such a company, define your requirements, let them review whether this is possible or not (maybe by sending such a test project), etc ... I think this will be more fruitful, less frustrating and not so time consuming at all.

Congrats!

Ramses, do you mean the daw should not use certain cores? Or do you mean some cores should only be used by the daw? I'm not sure how to do that with process lasso. I have attached a screenshot how I've set process lasso.
https://1drv.ms/u/s!AsNedAPvuG2thH0YBaU … 0?e=d9DLDb