Really a very helpful tool, many thanks for taking the effort :-)

Some feedback from my side:
- Tab "System" - very informative overview about the system's components
- In general, easy and straightforward to use
- Excellent/easy structure to go through all the points or to change everything at once.

A few comments and suggestions, maybe you like them.

1. Tab "System"

This overview is nicely structured, very compact and could be useful for other purposes.
It would be great to have an export button for exporting this information in text format.

2. Tab "Optimize" -> "Power Plan"

Some people might use other power plans like "Ultimate Performance" or "Bitsums Highest Performance" (in case you use Process Lasso Pro). Therefore, it could be useful to flag those "Optimal" as well.
There is no real need to switch to High Performance if you have one of the other two active.
They are not that much different, and you optimize the relevant settings anyway under "Power Settings".
It would also be useful if somebody uses "Apply all settings", so that no open topic remains.

3. Tab "Optimize" -> "Power Settins"

I would suggest two more settings
- slideshow -> "paused" to avoid any kind of latency spikes due to wallpaper changes
- wireless -> "max power" to get optimum WLAN performance if you have no possibility for LAN connection.

4. "Advanced" -> "System Sounds"

I prefer to turn them off so that they can't disturb me during monitoring or when recording a track,
and finally, to avoid the sound driver issuing some more unneeded interrupts.

5. "BIOS" -> "Settings Guide"

- I would suggest turning off "CPU Spread Spectrum". As far as I know, any clock changes introduce a little latency, because the clock can't change immediately without any delay. I never had any EMI issues in the past 25+ years.
So why not turning it off for an optimized setup?

- I would enable EIST (P-States): then you can control the CPU clock using Windows energy profiles

- Turbo Mode: Enable gives you a slightly higher clock (for me +200 MHz more)

- Enhanced Halt State (C1E): Disable, to prevent that the CPU goes into energy saving if it is idle, which increases DPC latency.

6. Optimize for background services

Based on my research and good experience with it for over 15 years, I would suggest optimizing the scheduler for background services so that the CPU can work a little bit longer on a task before having to perform a context switch.
https://www.tonstudio-forum.de/blog/Ent … es-or-not/
How are your experiences with that?

I am happy to use your tool as is.
But it would be kind if you could review my suggestions and - if you like - add some or all of them.

My system setup and tuning here: https://www.tonstudio-forum.de/blog/ent … esults-en/
I added your tool to this blog article.

Have a nice day and many thanks for your excellent contribution by such an "easy to use" tool.

The solution for such things is Process Lasso Pro.

It has many useful features, also regarding the use of suitable power profile.

1. You can configure a start profile; I am using "Balanced" as the default.
2. The feature "idle saver" takes care of switching automatically to, e.g. "Energy Saving" after configurable xx seconds of console inactivity.
3. Application-dependent power profiles. For DAW and other applications, I am selecting "Performance Mode" which switches to the configured profile, offering the highest performance, and which deactivates IDLE saver as long as this application runs.
4. It also has game autodetection (Steam), or you can also configure (add) games manually.

This gives the best overall functionality. Then you do not need to be too "shy" using Ultimate Performance.
It will only become activated if an application is being executed that is configured to issue "Performance mode".

EDIT:
It has run stably here for 8 years and worth every penny.
You get a lifetime license for an affordable price of €20.91 (single PC) or €31.37 (entire home up to 5 PCs).
https://bitsum.com/get-lasso-pro/
A very kind and customer oriented team, they fulfilled a lot of my wishes, and the tool is still getting regular updates.

Hi Matthias,

C1E is possibly redundant because the C0 setting doesn't allow you to reach C1 anyway.

EDIT: but there are systems where C0/C1 seems to be combined, where C1E still could make sense.
https://www.dropbox.com/scl/fi/xp84g0be … w&dl=1
Even if not, it wouldn't disturb and finally do what C0 would do.

Regarding the other suggestions, only a few additional comments.

It may be that, when considered in isolation, one or the other of the proposed changes might not seem significant enough.

However, in my experience, it is the cumulative effect of all these changes working together that determines, in borderline situations, whether glitches occur when using smaller ASIO buffer sizes or whether you can work with small buffer sizes or need larger ones.

The thing with optimization for background services has, IMHO, nothing to do with CPU architecture. It's more about the parameterization of the process scheduler. It controls the duration of the time quantum for task scheduling—how long each thread is executed before a context switch happens—and whether this is fixed or variable. A slightly larger and constant quantum results in fewer context switches and means higher efficiency when working on different tasks.
During DAW work, it is better for the system to work with constant quanta compared to changing ones and the overhead of frequent context switches. It's the DAW workload and audio-related jobs that need to be processed efficiently, not GUI or mouse movement, which is nowadays supported anyway by powerful GPUs.

It's comparable to ASIO buffer sizes. If you use the lowest one, the CPU load increases, and the CPU might not be fast enough to process audio in time.

Microsoft intended to give foreground tasks (GUI, mouse movement) a higher preference. But tbh, I never experienced any input lag with my systems in the past decades when configuring the scheduler for this constant and slightly larger time quantum. This tuning recommendation has existed since Windows XP, and I think the basic intention behind this never changed, even if Microsoft enhanced the process scheduler. These enhancements were primarily for GUI stuff, not for efficient DAW workloads.

Really lots of information, also in terms of building a system.

There are some comments from him where I would put a question mark, as they might come from a Microsoft view of things.
Like not disabling the Microsoft Store or OneDrive, or not activating Game Mode (which, e.g., turns off VBS).

Also, an ASIO driver runs interrupt-driven in kernel mode and has nothing to do with foreground processes, even if it is being loaded into the DAW. So this has, IMHO, nothing to do with the topic of "optimize for background services." There, I would have expected more concrete information about the advantages or disadvantages of having fixed or variable time quanta.

Some tweaks he mentions is more a matter of "taste", whether you want to have services like small apps running in the background or not.

You should not forget that CPU performance has increased significantly over year to make such things possible, also in combination with powerful GPUs.

But what’s still critical is, how efficiently the CPU can work to bring this performance best into play.

In that regard, I do not understand how he can come to statements to better trust your ears than tools like LatencyMon.
He fully ignores that this is the only quite easy-to-use tool to find out whether your system runs efficiently or is being blocked by wrong settings in the BIOS, Windows or by bad drivers allocating cores for too long.

Therefore I think this is a very undifferentiated view on system/DAW performance, especially if you would like to work with lower ASIO buffer sizes to get a lower RTL.

All in all, I think bighyunwoo brings it much better to the point of what's crucial for DAW operation under Windows to get an agile system.

Nevertheless, thanks for the link, the one or other information can still be useful, but I think less for this tool.

Some additional observations.

I made some additional tests to find out with my current system, whether optimization for foreground tasks or background processes is preferable for DAW work.

On the one hand, when comparing LatencyMon results, you can see that optimization for foreground tasks gives slightly better numbers.

On the other hand, when performing an application test, the picture looks different. Prioritization of background processes (larger and constant quanta) leads to fewer and more regular audio interruptions. Prioritization of foreground processes (smaller quanta and dynamic in terms of size) brings more frequent, irregular interruptions.

It’s difficult to judge. For me, it still sounds more logical that a system with fixed and longer quanta (if it's not too long) benefits from being able to process a workload more efficiently, as this also reduces the number of context switches, which for a CPU is simply overhead.

One difficulty with such measurings is, to find an easy reproducebale workload that makes it visible and audible which setting gives you more headroom when you are at the edge of what your system is capable to process.

For this comparison, I again used my DAW project with 400 tracks and 803 VSTs.
In parallel, LatencyMon runs to add even more stress—a second DAW load.

Finally, both settings (foreground vs. background) fail at an ASIO buffer size of 256; you get audio loss because running the DAW and LatencyMon together is too much stress. On the other hand, 400 tracks alone and 803 VSTs don’t create enough load; even with a 32-sample ASIO buffer size, it is stable.

That’s the problem of having to find a good, reproducible workload close to the edge.

But from what I heard, the audible pattern of audio loss with prioritization for background tasks didn’t sound as random or chaotic to me. Therefore, I conclude that this setting supports the system in processing the workload efficiently and thus I think this is still a good setting for an efficiently working system.

I completely forgot about this over the years, I can't remember when I last suggested this as a possible way to improve performance...

Quick comments to 1.1.0, well done.

Copying system information and saving debug logs works great.

What is the service notice feature? Sorry, I didn't find it.

It's good that in the TAB "optimize", the "Apply All Settings" only applies the settings in this particular tab,
because I do not want to apply, e.g. Exclusive Mode "per se" for all sound devices or to enable system sound
which I regard as disturbing when getting "ding dong" into the monitoring.
Some recommendations even tell to disable the on-board sound completely.
But I think this goes too far, as many people prefer an easy possibility to connect a headset for online communication.

In Advanced -> Sound devices
I find Korean letters in the English version. Is there a possibility to change this to English?

Optional, for a little additional "comfort".
What do you think about putting the version number into the title bar?
If somebody sends you a screenshot then you have automatically the version number visible.

Also for me or others useful when adding a version number to the downloaded binary, then I only need a quick start of the tool to have this information directly available. I prefer to save binaries with either version number or date to have different versions of a tool, e.g. for comparison whats the difference to the older versions.

Many thanks for your work.

I had a quick view; it looks excellent. More later; I need to go shopping before the public holiday

I find statements like “Those are old myths” too simplistic; they don’t do justice to the issue.

When dealing with very different workloads on a computer, you can’t simply make sweeping generalizations without considering the specific workload or the intended purpose—in other words, why you’ve chosen that particular configuration.

My intention is an agile system and stability even if there is a higher load.
And as there is as good as no information about this on the internet, I am testing such things with a real application test.

In my setup, using a Cubase "stress test project", both settings lead to slightly different results:
https://forum.rme-audio.de/viewtopic.ph … 55#p250455

It turns out that you achieve better stability with fixed quanta. In my application test with Cubase, using fixed quanta resulted in a different pattern of audio dropouts. While variable quanta caused more continuous "chaotic" audio loss, fixed quanta allowed for longer periods of uninterrupted playback. Which means "more stability under high load".

The same principle applies to changing clock rates. Adjusting the system clock introduces a small amount of latency, as clocks cannot transition in zero time. For this reason, a DAW setup using a stable, fixed CPU clock has always been recommended for more reliable operation compared to changing clock rates.

Fixed and longer quanta also ensure that the CPU works more efficiently across different tasks by reducing the overhead caused by frequent context switches.

This is comparable to working with smaller or larger ASIO buffer sizes: if the buffers are too small, the system is under more stress to process the audio load. The same applies to time slices (quanta) used to distribute processor time among different jobs. If the quanta are too small, it may benefit foreground applications or mouse movement, but the CPU has less time for working efficiently on each of the tasks, especially if the system load is high.

Of course, an excessively long quantum would also be counterproductive. Therefore, certain programming conventions exist so that the chosen values are in a range that makes sense.

Given my understanding of how these components interact, I still find that optimizing for background services—using fixed and slightly longer time quanta—provides distinct advantages.

EDIT: Also, consider a workload on a computer is never static; it constantly changes and can be very high at times.

You might have a small benefit with smaller quanta for the process scheduler when the workload is not so high.

But with higher workloads, it becomes more critical to work efficiently on all processes and get some work done,
avoiding any overhead like too many context switches.

Comparable to selecting a too low ASIO buffer size, which is, on the one hand, nice to have smaller RTL,
but on the other hand puts a burden on the CPU, having to work on audio I/O in much smaller quantities,
which increases CPU load, interrupt rate, and the likelihood of not being fast enough in processing audio
if the time frame for a CPU to work on the current process/thread is too small.

This applies, of course, for all CPU cores in a system. And the more cores you have, the lower your single-thread performance usually is, and the more you need to look to ensure that the single core does not become your bottleneck and can work efficiently.

The result of my stress test is that longer quantums bring more phases of audio stability
compared to the setting with smaller quanta, which results in more chaotic/continuous audio loss.

Then maybe a personal preference. I think it is more important to tune a system in a way that it performs best
even under higher loads.

Did you ever stress test your system to find out what setting leads to better results?
Then please tell me what you did and what the results were for you.

Unfortunately, there is very little information available regarding the parameterization of the Windows process scheduler and similar topics—and none known to me that examine this subject specifically for the requirements of a DAW load.
In a blog post on the matter, I was at least able to link a few sources that explain several things in connection with the process scheduler, see https://www.tonstudio-forum.de/blog/Ent … es-or-not/

In this area, one is dependent on one's own observations and must draw the correct conclusions from them. Ideally, one should possess solid foundational knowledge of how an operating system is structured, how kernel and user processes compete, how a process scheduler works, as well as expertise in the field of performance troubleshooting, etc.

I believe that, with the parameters you are currently configuring in the tool, you are well positioned. You are “in the green zone,” covering the essential elements that are universally recommended for all DAW systems. This also makes you less vulnerable, as criticism tends to arise quickly these days, often without any justification.

The challenge, however, is that these aspects are not easily measurable. At best, you can make observations, such as how often or how consistently distortion occurs under high load, and correlate these observations with your theoretical knowledge and experience.

To the 1st new option, "nVidia HD Audio"
Should prevent unnecessary polling of the ports, can be deactivated if you do not need those ports.
Deactivation either through Windows sound or by removing the nVidia HD related driver.

To the 2nd new option, "nVidia Low Latency".
EDIT: This seems to refer to the nVidia driver option "Modus für geringe Latenz" "Low latency mode".
Just discussing this with Hyunwoo via e-mail, not sure whether this is beneficial EDIT: in general terms.

In terms of the external tool.
That was PowerMizer Switch: https://nvworld.ru/utilities/pmswitch/

What I normally do in terms of nVidia are two things
a) To use PowerMizer Switch to disable power saving on the nVidia card
b) and in nVidia system control app
    - energy management -> prefer maximum performance

The other two optimizations that were proposed in a thread on the Steinberg Forum I can't recommend for the reasons below.
https://forums.steinberg.net/t/8-18-cor … tup/103725

- Threaded-Optimization should stay on the default setting, which is "AUTO"
   If you enable it, then SpectraLayers in Nuendo crashes the whole application

- Vertical synchronization: keep the default "Use settings for 3D-Applications" (translated by me)
   If you enable it, then applications like RME DIGIcheck NG or other apps are being displayed with the highest "fps"
   which fully utilizes your GPU, which means high GPU load, and you hear the blowers of your GPU working at full speed.