Thanks for the clarification. Would be really great to add that to the manual / problem or Windows section. That would have saved me maaaany hours of researching, testing, reporting and so on...

Real-time means here:

a) while the application is open
b) while the application is not only open, but also outputting an audio stream ?

I stumbled over one comment that I didn't read earlier.
Because its important for understanding the situation and LatencyMon I comment it now.

LatencyMon reports latency in the internal processing on your PC.

This is not an audible latency, but a latency in processing, so that time-critical jobs like audioprocessing  cannot be processed in time.

The technical background of this is that Windows (also macOS) is no real-time operating system.
Different jobs run in parallel: drivers and other running programs (Programs, Services, GUI, ..).

Drivers are not under the control of the operating systems process scheduler.
They run with the highest priority on the system for ensuring "data integrity".
Figure out what would happen when data transfers would be canceled during transmission.
Data would be incomplete / corrupted.

Therefore drivers have to detach themselves from a CPU core.
The time, how long the driver can occupy a CPU core is hardcoded in the driver and can not be changed.
Its simply based on "programming conventions".
But as we all know, there are good drivers and there are bad drivers.
If such a bad driver stays for too long on a CPU core and detaches itself too late,
then this CPU core can not serve other processes that have been scheduled by the job scheduler of the operating system to run on that core.

Then this job has to wait until this particular core becomes free (until the driver detaches itself from the core).

If this time is too long, then audio loss can occurr.

LatencyMon issues a DAW load on your system and measures the resposiveness of your system, how fast CPU cores react on the DAW load.
This is the Latency that LatencyMon reports.
If this Latency is higher than 1ms then the system is reported to be not suitable for processing audio / real-time tasks.

But even if this value is a bit below 1ms higher values show, that your system can not react agile on a real-time workload and process audio as fast as possible.

Depending on the system load this means to you that audio loss will much more likely occur the closer you are to the 1ms "processing" latency.

You can compensate it up to a certain point with higher ASIO buffersizes, but not full, because a latency of 1ms or higher is simply too high for a system that has to process audio in near-realtime.

The higher the DPC Latency, the more the likelyness for audio drops and especially when using smaller (ASIO-) buffer sizes.Therefore