No Problems detected. Everything is in the green and it says that my system is suitable for handling real-time audio.

https://drive.google.com/open?id=1C1MPW … HhVIp3cn4l

Doing a LatencyMon test run is the best we have currently to get a 1st impression, whether a system has load problems that can impact audio.

But most people have no experience how to use this tool. Without this knowledge the measuring results can be completely meaningless.

Please allow me therefore to give some explanations
- why we can get audio problems
- how LatencyMon can support us
- how to use it
- how to report the results to the public

This is a little bit long I know .. but otherwise I fear, that we get only meaningless values of poor quality.

Reasons for audio outages
If you get audio outages the reason is, that the CPU was not quick enough to
- transport audio between recording interface and application and vice versa
- to process audio inside the DAW

Windows is not a real time OS
One thing you should always think of ...
Windows is not a real-time operating system (also not Mac OS X) !!!

Process scheduler and its limitations
A process scheduler tries to handle the different programs on your system as best as it can. But when it comes to the execution of hardware drivers they have the highest Prio on a system andneed immediately to be executed. They can not be interrupted by the process scheduler.

So if there is a time critical job to transport or process audio and the process scheduler assigned a CPU core/thread to this audio process where such an interrupt  service routine is being executed, then the audio related process has to wait until the driver gives the CPU free.

Potential issues on driver level
If the driver doesn't follow certain programming conventions to give the CPU free then this can become a major problem in your system, when you use very low ASIO buffer sizes and in combinations with a loaded system. Where system load can be a combination of CPU load, interrupt load, I/O load (disk i/o). All this load piles at the end up to a likeliness, that your system can not process audio in time without raising ASIO buffers to much higher values.

The best Audio System is
So the best audio system is a system
- with good drivers (following certain programming conventions not to block CPU for too long)
- with all hardware/drivers being disabled which are not required (to reduce interrupt load and likeliness that CPU becomes blocked by low level routines too often)
- where no (or as few as possible) background jobs are being executed while you do audio processing
- with many CPU cores so that the program / driver load can distribute over more CPU cores
- but IMHO not too many cores so that it still fits for applications which need a high single thread performance
- enough DRAM

The purpose of LatencyMon is now to support us to detect
- how quick your system can respond to a test workload of LatencyMon
- to display how many time is being spend by the different drivers
- an ample function whether a system is able to handle audio well

Careful interpreting "LatencyMon's" Ample Function "your system is suited to process audio / or not"
One word to this ample function upfront. Even if LatencyMon shows "green", this does not mean that your system is really well suitet for processing audio. LatencyMon alarms when there was a peak of around > 1000 microseconds.
It is already bad, if you can see, that your system has a very high base load.
Not high enough to exceed LatencyMon's triggers, but still bad enough that you need to adjust ASIO buffer to higher values than you might want or expect.

How to use LatencyMon
1. Run it on an IDLE system (no started applications, no mouse movement as this also generates interrupts)
2. Let it run for at least 10 minutes to get a 1st impression
3. look at the values for
- Win7: kernel timer latency [microseconds]
- Win8/10: interrupt to process latency [microseconds]
There is no display of min or average values, so you need to instantly watch these number and need to make some notes on paper about
- min values
- typical average values
- recurring peaks
Absolute peaks the tool reports to you one line below.

Especially interesting are the min and the typical average values.
1st shows you whether your system is very agile.
Too high values here show 2 things
- most likely energy saving in the BIOS adds too much latency, this could be optimized
- too high process and/or interrupt load

How to treat the LatencyMon results after stopping the report:

1. copy/paste the report results to a file. Ctrl-C copies the report to a copy buffer.
2. Make a screenshot, preferable when LatencyMon shows the lowest values
    to see what the best values can be on your system.
    Screenshot to dropbox -> post it on forum
3. look at drivers tab
- make the columns narrower that you can see
-- ISR count
-- DPC count
-- Highest execution time [ms]
-- Total Execution time [ms]
4. Sort for Highest execution time
5. Make the window as tall as possible to see the Highest execution time of all Driver files (> 0)
    These are around 32 lines for my system, varies per system
6. Make a screenshot, place it to dropbox
7. Post screenshot
EDIT: 17:31:
8. Tell the values that you wrote on a piece of paper while watching LatencyMon running
- Win7: kernel timer latency [microseconds]
- Win8/10: interrupt to process latency [microseconds]
-> min values
-> typical average values
-> recurring peaks

When talking about Latencies ... differentiate clearly between these two ....
But whatevery we talk about optimizing here .. its about the agility of the CPU to process a current task in time.
Its the delay / latency when the CPU was actually able to perform something .. sometimes sooner, sometimes
later because of an always changing system load caused by programs, services, interrupt requests.

But this latency has ABSOLUTELY NOTHING to do with the latency / Round trip time of audio transport
via PCIe / USB / Firewire / Thunderbolt between PC and Recording Interface.
This is always static and being reported by the ASIO driver to the DAW.

If you i.e want to play guitar over a virtual amp, then this delay between playing a string on guitar
and listening it then over phones connected to the recording interface only depends on the
- Round Trip time between Recording Interface  and PC (as being told by the ASIO driver)
- Processing time for the amp simulation (VST) in the DAW
You need to adjust the ASIO buffer size that the round trip time is best below 12ms.
With an UFX+ you achieve this i.e. with an ASIO buffer size of 256, better 128.

When we talk about system fine tuning and measuring with LatencyMon we only want to ensure, that the CPU is not busy with other things or delayed by energy saving, interrupt processing, bad drivers, unnecessary system load, so that there is always enough headroom to process audio in time.

This sounds as if you worked with your PC and did a measuring in parallel.
Then these measurings do not bring anything.

By this you can't see / measure the "basic load" that your system already has when no user application is running.

This is what we need to find out, to see how loaded your system is already by pure
- interrupt processing
- background programs
- programs started in the background by the Windows Task Planning Service
- energy saving which still might by enabled in the BIOS
- potentially wrong energy profile in use
- results of a certain delay of CPU core parking

Please read and try to understand my post #5 for what pupose this tool is to be used.
I tried to tell it in easier words.

A more thorough explanation you find on the Webpage of Resplendence Software:
http://www.resplendence.com/latencymon

I ran a test for 47 minutes and took notes this time.

Minimum values on the "current measured interrupt..." was about 51-54.

Average values for "current measured interrupt..." was 89. Peak values were 103, 104, 109, 120

Average values for "highest measured interrupt..." were 156, 192, then 221. Minimum and Peak values were about the same.

Average values for "highest reported ISR routine..." were 191, 205 then 229. Minimum and Peak values were about the same.

Average values for "highest reported DPC routine..." were 301, 302, then 338. Minimum and Peak values were about the same.

Screenshot:
https://drive.google.com/open?id=1VGGlH … 7fGxdUZptl

Report Text:
_________________________________________________________________________________________________________
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:47:43  (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        THE-DANDELION
OS version:                                           Windows 10 , 10.0, build: 15063 (x64)
Hardware:                                             All Series, ASUS, ASUSTeK COMPUTER INC., Z97-A
CPU:                                                  GenuineIntel Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Logical processors:                                   8
Processor groups:                                     1
RAM:                                                  32709 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   40 MHz
Measured CPU speed:                                   1 MHz (approx.)

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

Highest measured interrupt to DPC latency (µs):       219.904338
Average measured interrupt to DPC latency (µs):       0.912870

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

Highest reported total ISR routine time (%):          0.769161
Driver with highest ISR total time:                   Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in ISRs (%)                          0.820035

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

Highest reported total DPC routine time (%):          1.217266
Driver with highest DPC total execution time:         Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in DPCs (%)                          1.308012

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

Process with highest pagefault count:                 none

Total number of hard pagefaults                       0
Hard pagefault count of hardest hit process:          0
Highest hard pagefault resolution time (µs):          0.0
Total time spent in hard pagefaults (%):              0.0
Number of processes hit:                              0

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       436.324852
CPU 0 ISR highest execution time (µs):                159.766250
CPU 0 ISR total execution time (s):                   175.917471
CPU 0 ISR count:                                      48533312
CPU 0 DPC highest execution time (µs):                338.082250
CPU 0 DPC total execution time (s):                   284.288564
CPU 0 DPC count:                                      59076091
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       25.998036
CPU 1 ISR highest execution time (µs):                229.570
CPU 1 ISR total execution time (s):                   11.581408
CPU 1 ISR count:                                      802598
CPU 1 DPC highest execution time (µs):                338.499250
CPU 1 DPC total execution time (s):                   9.008490
CPU 1 DPC count:                                      831407
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       9.920523
CPU 2 ISR highest execution time (µs):                137.940
CPU 2 ISR total execution time (s):                   0.293146
CPU 2 ISR count:                                      1675041
CPU 2 DPC highest execution time (µs):                213.18450
CPU 2 DPC total execution time (s):                   4.290528
CPU 2 DPC count:                                      1836311
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       6.677155
CPU 3 ISR highest execution time (µs):                63.65850
CPU 3 ISR total execution time (s):                   0.043098
CPU 3 ISR count:                                      130504
CPU 3 DPC highest execution time (µs):                128.60550
CPU 3 DPC total execution time (s):                   1.347132
CPU 3 DPC count:                                      411474
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       5.288204
CPU 4 ISR highest execution time (µs):                0.85550
CPU 4 ISR total execution time (s):                   0.000004
CPU 4 ISR count:                                      19
CPU 4 DPC highest execution time (µs):                69.010
CPU 4 DPC total execution time (s):                   0.232438
CPU 4 DPC count:                                      105256
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       5.356392
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):                68.7670
CPU 5 DPC total execution time (s):                   0.066146
CPU 5 DPC count:                                      23746
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       5.221563
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):                68.75150
CPU 6 DPC total execution time (s):                   0.296499
CPU 6 DPC count:                                      110512
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       5.254919
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):                68.42850
CPU 7 DPC total execution time (s):                   0.080041
CPU 7 DPC count:                                      25991
_________________________________________________________________________________________________________

I have an additional idea.
We did see with LatencyMon on an idle system, that your system should be able to run audio.
But a system might behave differently when being under load.
There is still a chance that you get Latency Spikes when your typical applications are running.
You can use DPC Latencychecker to get a nice graph over time.
http://www.thesycon.de/eng/latency_check.shtml

This result is with Cubase 9.5 and the new demo project running ...
EDIT: MADIface driver 0.9616, ASIO buffersize 128. Same results with ASIO buffersize of 32.

I made another test which puts more load on my system.
The setup is documented here: https://www.tonstudio-forum.de/blog/ind … cks-de-en/
400 tracks of a Lee Ritenour Song where each of the tracks has 2 Cubase VSTs loaded.

ASIO Buffersize at 32 samples ..
CPU load on average: 30% (26 ... 38%)
16 GB DRAM in use out of 32 GB.

The same plus additional 2 VSTs: Superior Drummer 3 and Trillian, still with ASIO buffer size at 32 samples

ASIO Buffersize at 32 samples ..
CPU load on average: 40% (36 ... 49%)
16 GB DRAM in use out of 32 GB.

Good morning, I would suggest to open a new thread, as you have a different system and this here was 4y ago.
If you want you can give a reference to this thread by addining the URL of it.