Topic: UFX+ vs MAUDIO2x2m and total despair !

Dear RME and RME community,

I have made a significant investment in purchasing the RME fireface ufx+ after a careful decision process ending in trusting the world renowned RME drivers in part.

I come from a basic entry level soundcard, the MAudio 2x2M. I was expecting an earth shattering jump in performance, sound quality etc.. as I rightly did I believe, since the 2 cards are pretty much at opposite ends of the spectrum...

The issue:
With everything else being the same, the fireface cannot handle the load of my projects using ableton live as well as the Maudio.
More precisely, I hear cracks and pops, glitches and digital noise etc.. while playing back my work whereas with the MAudio this does not occur. (Same project file and buffer settings). An easy fix is to increase the buffer size, but it seems strange (to say the least) that I need to increase the buffer size when compared to the maudio !

I have tested this with a local RME engineer here in Hong Kong. The hardware seems ok, no error reported by the usb monitoring system as well. I’ve tried a long list of potential fixes without any hope left.

Is it normal that the Maudio card processes audio faster than the high end product I’ve invested so much effort in purchasing ?

I’m at a loss.
Specs:
XPS 15 9570 core i9 32Gb
Windows 10
Live 10 latest version
All drivers and firmwares up to date.

I use mostly audio samples and software synths. For example, Diva from u-he is handled better with my Maudio than with the fireface !

With 3 instances of Diva and nothing else and 256 buffer size audio glitches are very very obvious.
Nothing unusual with the Maudio at 128 !

For me the fireface ufx+ is a downgrade in this regard.

Ive tired:
Different USB ports
Thunderbolt usb 3
Disabled various drivers on my system
Different hardware settings.
Performance mode
Disabled sleep mode
and more.

I’ve been told the windows platform is the issue and Mac is better.. Again, Maudio has better compatibility with windows than RME ?..

I rarely if ever post online for help as I’m usually fairly adept at fixing issues of this nature by myself ... but in this case, short of formatting the laptop and even then, no idea what to do.
Thank you for anyone’s help with this issue.

2 (edited by ramses 2019-12-18 13:54:46)

Re: UFX+ vs MAUDIO2x2m and total despair !

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 ?

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

Ramses, thanks so much for your reply !
I’m feeling a glimmer of hope.
Yes I agree, the comparaison is purely superficial. And your point about having already present underlying issues is very good and would explain a lot.
I’ve spend the better part of the afternoon with a tech representative for RME, and was a bit disappointed to be honest.
Your suggestion about tweaking the bios didn’t come up.

The interface is still being double checked for potential hardware issues. But I’m pretty sure it’ll come back fine. In the mean time I’ll make the modifications you suggested and will update tomorrow hopefully with good news.
Thanks again, I really want to try and avoid blindly formatting the laptop to probably end up in the same spot after days of re-installations and configurations etc.

4 (edited by ramses 2019-12-18 16:37:17)

Re: UFX+ vs MAUDIO2x2m and total despair !

> 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.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

LatencyMono results at the end of the post.

Well, I’m nowhere near as knowledgeable as you are on the subject of computer audio, that’s for sure !
My laptop has good specs: core i9, 32gb ram, blazing fast compared to what I owned previously. However, I have no pro audio computer system reference point. It’s actually designed to handle heavy video editing I believe.
Anyway, it has a quite a bit of customization potential in the bios, this is what I’ve done just now:
1. Ive disabled Intel SpeedStep (see pic below)
2. Ive found the option to disable C states so that’s done (see pic below)
3. Ive kept Intel TurboBoost on, should I turn it off ? (See pic below)
4. Ive kept Intel speed shift Technology enabled, also I’m not if i should (see pic)
5. Ive enabled the block sleep option, cause why not
6. There are a few Thunderbolt settings in the bios as well, havent messed with them, not sure if that would help ?
(See pics)

I’m on to your newer post and the suggestions you mention in it.
Sadly I’m gonna have to wait to test if those change have had an effect until tomorrow when I see the tech again.

Oh and I've also run LatencyMon PRIOR to all those changes.
I will run it again and post both results shortly.

thank you SO much !

all pics here: https://drive.google.com/open?id=1oDgJb … yACEINfkgJ
havent figured out how to upload pics yet.


______
Latency Monitor:


_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. At least one detected problem appears to be network related. In case you are using a WLAN adapter, try disabling it to get better results. 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:01:26  (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:                                                  32499 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):   8838.30
Average measured interrupt to process latency (µs):   4.846188

Highest measured interrupt to DPC latency (µs):       8790.40
Average measured interrupt to DPC latency (µs):       1.806734


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

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

Total time spent in ISRs (%)                          0.002415

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

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

DPC count (execution time <250 µs):                   424710
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                207
DPC count (execution time 1000-1999 µs):              4
DPC count (execution time 2000-3999 µs):              1
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:                 serviceshell.exe

Total number of hard pagefaults                       11993
Hard pagefault count of hardest hit process:          1231
Number of processes hit:                              72


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       2.822857
CPU 0 ISR highest execution time (µs):                456.975551
CPU 0 ISR total execution time (s):                   0.024920
CPU 0 ISR count:                                      586
CPU 0 DPC highest execution time (µs):                738.8750
CPU 0 DPC total execution time (s):                   0.223197
CPU 0 DPC count:                                      128648
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       4.457461
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):                561.870523
CPU 1 DPC total execution time (s):                   0.012505
CPU 1 DPC count:                                      17801
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       3.078509
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):                2131.456956
CPU 2 DPC total execution time (s):                   0.094747
CPU 2 DPC count:                                      25125
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       2.933961
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):                555.094008
CPU 3 DPC total execution time (s):                   0.010074
CPU 3 DPC count:                                      16337
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       2.912230
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):                236.891529
CPU 4 DPC total execution time (s):                   0.016073
CPU 4 DPC count:                                      21736
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       2.853533
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):                264.059229
CPU 5 DPC total execution time (s):                   0.015289
CPU 5 DPC count:                                      15386
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       2.486781
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):                423.711088
CPU 6 DPC total execution time (s):                   0.015744
CPU 6 DPC count:                                      21202
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       2.501625
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):                384.738292
CPU 7 DPC total execution time (s):                   0.008160
CPU 7 DPC count:                                      13393
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s):                       3.886670
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):                336.815771
CPU 8 DPC total execution time (s):                   0.018104
CPU 8 DPC count:                                      20873
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s):                       2.349466
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):                322.665978
CPU 9 DPC total execution time (s):                   0.008392
CPU 9 DPC count:                                      13484
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s):                       4.450757
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):                802.334711
CPU 10 DPC total execution time (s):                   0.145237
CPU 10 DPC count:                                      117262
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s):                       4.083186
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):                455.297176
CPU 11 DPC total execution time (s):                   0.011112
CPU 11 DPC count:                                      13675
_________________________________________________________________________________________________________

Re: UFX+ vs MAUDIO2x2m and total despair !

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
_________________________________________________________________________________________________________

Re: UFX+ vs MAUDIO2x2m and total despair !

Forgot to mention:

No error in the usb diagnosis in the RME settings dialog
Cables are all under 2m or under.
I only have 2 usb 3.1 gen 1 ports, no usb 2.
And
1 thunderbolt 3 port

And I have now prioritized background tasks.
Ok, im feeling good about all this, haha.

Should have taken the ufx+ back with me,
but what i can do in the mean time is to test all these new settings with my old interface.
I may already see some improvement.
Will keep you posted.

The worse case scenario is investing in a new computer I guess, what would you recommend ?
A macbook pro if i want to keep it mobile ? Not a windows OS I guess...
Or just a desktop mac ?

Re: UFX+ vs MAUDIO2x2m and total despair !

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

Re: UFX+ vs MAUDIO2x2m and total despair !

In regards to optimization for background processes see my blog.

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

Esp. realtime anti virus scans, surely non beneficial.

Your new Latencymon figures are much better.

I am pretty sure that process lasso pro would be additionally beneficial for you. If you have 6c/12t then you could try to dedicate 3c/6t or even 4c/8t to the DAW process. Run Process Lasso Pro as service so that it can control all processes and threads of the system.

Wheather it was good to disable WLAN, sometimes yes. You need to measure a lot
What a single change brings and the sum of several changes.

Not 100% sure whether disabling speedstep is OK. Might be because if you disable cpu core parking it can be the case that some core's can not reach Turbo speed. But a high sustained speed / clock might be better anyway as clock changes might also cause a little delay until new clock rate is stable/reached.

I use LatencyMon with a different setting to measure kernel latency timer. On a very good optimized system (mostly desktops) the latency timer goes down to 1.75 microseconds and has usually values between 5 -40 microsecons with rare peaks up to 80 or 100.

I can't promise anything from distance but after some finetuning you should get it to work reliably.

Never forget ... the quality of tuning a pc or laptop for audio is the sum of all tweaking here and there like in formula 1.

Best is to backup your system with Macrium reflect. If you think you changed too much then you can go back reliably.

For the bios part make picture of default / initial settings.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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

11

Re: UFX+ vs MAUDIO2x2m and total despair !

This seems to be a bit over the top. According to the first Latency Mon results and confirmed by disabling WiFi the whole cause seems ti be a shitty WiFi or network adapter. I would get back to default settings in BIOS and only disable WiFi, then test again. If confirmed search online for newer drivers for that device, then Google if that specific device is known for DPC problems.

Regards
Matthias Carstens
RME

12 (edited by adrien852 2019-12-19 06:54:17)

Re: UFX+ vs MAUDIO2x2m and total despair !

MC wrote:

This seems to be a bit over the top. According to the first Latency Mon results and confirmed by disabling WiFi the whole cause seems ti be a shitty WiFi or network adapter. I would get back to default settings in BIOS and only disable WiFi, then test again. If confirmed search online for newer drivers for that device, then Google if that specific device is known for DPC problems.

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...

13 (edited by adrien852 2019-12-19 07:17:11)

Re: UFX+ vs MAUDIO2x2m and total despair !

Voila,
With the inital BIOS settings ie:
C States enabled
SpeedStep enabled.

AND wifi and antivirus real time scanning disabled.

MC, here's the clear cut answer:
45 seconds later LatencyMon gives this:


_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. 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:00:37  (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):   7797.80
Average measured interrupt to process latency (µs):   4.769574

Highest measured interrupt to DPC latency (µs):       7795.30
Average measured interrupt to DPC latency (µs):       2.006864


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

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

Total time spent in ISRs (%)                          0.002955

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

Highest reported total DPC routine time (%):          0.008797
Driver with highest DPC total execution time:         storport.sys - Microsoft Storage Port Driver, Microsoft Corporation

Total time spent in DPCs (%)                          0.036951

DPC count (execution time <250 µs):                   119029
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                58
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:                 xtuservice.exe

Total number of hard pagefaults                       8755
Hard pagefault count of hardest hit process:          1858
Number of processes hit:                              37


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       1.793878
CPU 0 ISR highest execution time (µs):                278.870868
CPU 0 ISR total execution time (s):                   0.013122
CPU 0 ISR count:                                      479
CPU 0 DPC highest execution time (µs):                807.940771
CPU 0 DPC total execution time (s):                   0.088667
CPU 0 DPC count:                                      46521
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       2.821960
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):                36.584022
CPU 1 DPC total execution time (s):                   0.002416
CPU 1 DPC count:                                      3263
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       1.855683
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):                100.749311
CPU 2 DPC total execution time (s):                   0.013418
CPU 2 DPC count:                                      10536
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       1.886450
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):                82.265840
CPU 3 DPC total execution time (s):                   0.002023
CPU 3 DPC count:                                      3224
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       1.610172
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):                217.789601
CPU 4 DPC total execution time (s):                   0.007741
CPU 4 DPC count:                                      6943
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       1.622924
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):                334.020661
CPU 5 DPC total execution time (s):                   0.007050
CPU 5 DPC count:                                      5345
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       1.266282
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):                74.669766
CPU 6 DPC total execution time (s):                   0.007563
CPU 6 DPC count:                                      7845
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       1.265109
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):                27.206267
CPU 7 DPC total execution time (s):                   0.001089
CPU 7 DPC count:                                      2126
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s):                       1.897492
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):                139.409780
CPU 8 DPC total execution time (s):                   0.005816
CPU 8 DPC count:                                      5789
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s):                       1.242211
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):                34.456956
CPU 9 DPC total execution time (s):                   0.002288
CPU 9 DPC count:                                      3373
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s):                       2.488420
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):                300.282025
CPU 10 DPC total execution time (s):                   0.023891
CPU 10 DPC count:                                      20387
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s):                       2.309714
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):                109.545799
CPU 11 DPC total execution time (s):                   0.00210
CPU 11 DPC count:                                      3735
_________________________________________________________________________________________________________



I've spent the afternoon yesterday with the tech in real time in his office,
I've gotten a reply from RME directly with a few basic suggestions...
There was only 1 suggestion that worked and that was ramses',
again, I'll need to plug in the ufx+ later, but this looks promising.

Re: UFX+ vs MAUDIO2x2m and total despair !

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.

Re: UFX+ vs MAUDIO2x2m and total despair !

just a FYI, cheaper audio interfaces are often not honest about buffer settings. They claim a 64 samples buffer but forget to mention the 256 safety buffer (or whatever) or that they use double or quad buffers so 64=128 or 256.
The m-audio working at 32 is highly unlikely. Sometimes looking at the latency reported in your daw gives a clue to the real buffers size. But even there, there are often errors.

Getting good laptops for audio work is difficult and macs are not a sure thing either. If you can afford it get one from a pro daw builder.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

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 !

17 (edited by ramses 2019-12-19 12:29:12)

Re: UFX+ vs MAUDIO2x2m and total despair !

What country are you from ?

Besides this I still would give it a try to pin daw processes to specific cpu cores under the assumption that process lasso pro takes care that all other processes and DPC run than on other cores.

At the end the longer taking DPC can not be interrupted by the windows task scheduler. So a separation of audio process and rest of tasks / threads could lead to good results. You need to experiment a little.

Setting C States to C0/C1 also might avoid some lag by cpu not entering sleep states. Also here you need to experiment.

As MC said there might be settings that bring more or less. With Laptops you also need to observe Temperature. But thats the way to go. If you get no drivers which are not blocking the cpu too much then you need to try and experimental much or get other hardware.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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.

Re: UFX+ vs MAUDIO2x2m and total despair !

A good way to see if you are using the power of this machine is to see what your cpu usage is when things go south (crackling). If it is plus75% this is good. If sub 50% it is less so.
A project that is 75% cpu and runs good at 512 will probably not run at 64 samples. 256 maybe yes.
Still there are plugins too that are less optimised for very low latency.
Another thing is that expecting a huge difference in performance in favour of the rme cpu wise might also be somewhat unrealistic. You have such a powerful computer that the extra overhead the driver takes is less significant then in the past (IMHO). It all depends what the real buffers of the m-audio are if you want to compare.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

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.

Re: UFX+ vs MAUDIO2x2m and total despair !

at Ramses: I live in Hong Kong.

Re: UFX+ vs MAUDIO2x2m and total despair !

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

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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

Mainly in features and audio quality. Maybe somewhat in low latency performance but that depends on how bad the m-audio drivers are. 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 DPC should be low, that is for sure.
For real buffer sizes you can look at what the driver reports to your daw latency wise. Check all buffer sizes! And write it down!
For benchmarking I use dawbench. But I have been on the same machine now for years and years. Still a core2quad, this CPU was launched in 08. Last generation before the core iX

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

“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 ?

Re: UFX+ vs MAUDIO2x2m and total despair !

adrien852 wrote:

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

OSX is not realtime too, it literally uses the same hardware .
Asio is better then core audio.
Free choice of hardware, build it myself.
Mac used to be more for pros, but is now more for the hip/status.

The things that cripple this laptop would also cripple OSX. Yes the CPU has much raw power but size (cooling) and battery saving are working against low latency.

But, some software might run better on one of the two OS's. When I build my system (hand-picked indeed) Cubase ran much better on windows, much better. Logic runs better on a mac, LOL. Ableton, I don't know.
And RME was much better then my EMU PCI card at lowest latencies (not much difference above 256).

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

26 (edited by ramses 2019-12-19 19:45:20)

Re: UFX+ vs MAUDIO2x2m and total despair !

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/

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

Or you could, also, install Mac OSX on a separate SSD(Hackintosh), make your comparisons and decide which is the best for you! I don't know about any compatibility issues, though, with your current hardware..You 'll need to do a bit of a research!
I'm a windows guy, though, and haven't tried it myself.

RME Gear: Digiface USB, HDSP 9632

28 (edited by adrien852 2019-12-20 08:30:17)

Re: UFX+ vs MAUDIO2x2m and total despair !

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+!

29 (edited by ramses 2019-12-20 12:08:06)

Re: UFX+ vs MAUDIO2x2m and total despair !

Kernel latency timer was the initial measuring method in v4.03. With win8 and 10 this was not  possible anymore but with higher versions of LatencyMon  (maybe also of Win 10)  it came back for later versions of LatencyMon 6.x.
At least the resulting values looked more accurate to me again.

But tbh  I am still not 100% sure whether we see now the same values of kernel latency timer as under Win7 with LatencyMon v4.03. Maybe somebody should ask the developers of this tool on their forum.

For me the kernel latency timer is the most interesting one because it offers smallest values down to 1.75 microseconds which means to me higher measuring resolution.

If you perform changes in the BIOS in the area of energy saving then you need this higher resolution in the microsecond area to see the differences.

My interpretation of this value is, how quick a cpu core can respond to a workload.
Therefore I measure on an idle system to find out whether the responsiveness is as expected or whether there is still something not optimum and keeping cpu cores busy.

The lower the kernel latency timer values are, the quicker the CPU'S are able to process a workload (process, thread).
Then the system is better able to directly start processing ie an audio related task so that audio data can be processed in time.

To be clear on that value:
Lower kernel latency timers don't give you better RTL for your recording interface.
But it reduces the likeliness for audio loss under load or when working with smaller ASIO buffersizes.

Values up to 1000 microseconds = 1ms are allowed, otherwise the cores are blocked for too long by other stuff (DPC, processes, threads) and the system is regarded as being too slow to process audio (in near realtime).

IMHO recurring values over 100 us are already quite high if you want to squeeze max performance out of your system.

On an optimum tuned and idle system you should be able to see recurring values in the range  of 5-40 microseconds. Absolute min values around 2us down to 1.75 and rare max peaks of around 80-100 us.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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...

Re: UFX+ vs MAUDIO2x2m and total despair !

Removing the troublesome core from being used by ableton, might help reduce latency but at the expense of cpu power...

Re: UFX+ vs MAUDIO2x2m and total despair !

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.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

You can see in the tabular of this article what latencies different c-state settings are causing. Therefore it's basically a good strategy to disable energy saving to avoid these latencies.

http://www.tonstudio-forum.de/blog/inde … -X10SRi-F/

You only should be careful with laptops and heat. If CPU'S become too hot, then clock speed will be throttled which is counterproductive. Maybe it could also damage the CPU if this throttling does not take place or too slowly.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

Yes sorry, i forgot to upload them, here are the values, what you say is not wrong...
https://drive.google.com/open?id=1chXnd … cbk7Y2Tekk

Re: UFX+ vs MAUDIO2x2m and total despair !

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...

37 (edited by adrien852 2019-12-20 13:00:07)

Re: UFX+ vs MAUDIO2x2m and total despair !

Diva and Zebra a very good softare synths vsti developed by u-he..
I am jusing them as a load inside ableton to test the response of the system with the ufx+ or the Maudio.

Re: UFX+ vs MAUDIO2x2m and total despair !

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.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

@adrien852

Have you tried the "Limit ASIO to 32channels" option on the FireFace settings? It can be found on the "About" Tab
Also, you should set the "Optimize Windows for" Option to "Background Tasks".

RME Gear: Digiface USB, HDSP 9632

Re: UFX+ vs MAUDIO2x2m and total despair !

adrien852 wrote:

Diva and Zebra a very good softare synths vsti developed by u-he..
I am jusing them as a load inside ableton to test the response of the system with the ufx+ or the Maudio.

Yes very nice synths!

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

The latter I suggested already in post #4 but am not sure whether he performed this change.
Good idea to limit ASIO to 32 channels. In this or another thread I suggested to take usb2 what's also possible, but this is indeed easier to be performed ;-)

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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

Re: UFX+ vs MAUDIO2x2m and total despair !

I performed all the changes suggested and more.
And even tried various combinations of changes etc...

Re: UFX+ vs MAUDIO2x2m and total despair !

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

Re: UFX+ vs MAUDIO2x2m and total despair !

I think the measurings under load are simply waste of time. Why ?
1. You need to fix the root cause which is the "lag" in your system.
2. It's only possible to identify the lag by measuring an idle system.
Once you get the lag in your system fixed then you will automatically have no issues with the UFX+.
I operated two (!!) UFX+ and one ADI-2 Pro FS on my system and had no issues.

BR
Ramses
X10SRi-F, E5-1650v4, Win10Pro20H2, Cub11Pro, UFX+ (v0.9735), XTC, 12Mic, ADI-2 Pro FS R BE

Re: UFX+ vs MAUDIO2x2m and total despair !

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...

Re: UFX+ vs MAUDIO2x2m and total despair !

ramses wrote:

The latter I suggested already in post #4 but am not sure whether he performed this change.

Aah, yes! Lots of info in this thread, and I forgot that you did!

About the "Limit ASIO", I got the idea of your second post, where you mentioned that the UFX+ has to transfer all its channels, eventhough they are used or not! smile

RME Gear: Digiface USB, HDSP 9632

Re: UFX+ vs MAUDIO2x2m and total despair !

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...

Re: UFX+ vs MAUDIO2x2m and total despair !

I would also test with another lighter synth. Which can play lets say 30 tracks/instances or more on your system and then see how that goes.  6 synths on 6 cores on the edge of breakup is not 100% informative. There is not much load balancing windows/ableton can do. Or a little lighter patch with diva and just one voice so you can run many. Bringing the system down is not a test per se. It is interesting of course, but might just be the many more channels of the ufx .

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632

Re: UFX+ vs MAUDIO2x2m and total despair !

I checked you figures again and indeed with 6 zebras the rme wins. Strangly 5 zebras is worse...

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
Babyface pro fs, HDSP9652+ADI-8AE, HDSP9632