[2.0.0]I built a free Win optimization tool for audio/video production (Page 1 of 2)

I fixed the broken download link in your post and tried the software - and like it a lot! Especially as it also covers the settings that I found to turn my Dell notebook from unusable to well performing already a year ago (clicks and dropouts at lower buffer settings were horrible) - that was the (unexpected) Power Settings section, and I found it using the free PowerSettingsExplorer in combination with the free QuickCPU tool.

I give your software a thumbs up and would encourage anyone reading here to try it. Especially as you can revert to default anytime, plus have full control of what you change.

But I also like to add a bit of my Dell experience:

- The Dell 9530 does not allow Core parking. The BIOS permanently checks that and sets it back after a few seconds. Other notebooks might do the same for obvious energy consumption reasons.

- Setting processor min to Max instead of 5% (Default) made zero change for me

- High Performance power plans typically do not exist for notebooks anymore. These are intended to be used mobile and energy efficient, so MS (AFAIR) removed that. But in my testing I also found it to be no issue at all - at least on this Dell, Balanced with the other settings applied (I called the power plan Low Latency Optimized) is a big improvement already.

- What I really want to check, and your tool makes this super-easy, is the sleep mode of all the USB controllers. I typically have no issue with sleep active, but when I tested the StarTech TB33A1C I ran into exactly this issue - in the most extreme way! This unit is the equivalent of the PCIe cards with multiple USB3 controllers, but based on Thunderbolt, and thus usable even with notebooks. And it completely failed for me under Windows. Setting the included controllers to always on helped a bit, but maybe your tool can get this (currently piece of junk) start to work as intended. Unfortunately we will have to wait until May for that test to happen.

I’ll take a look later. I’ve done what I think are all the tweaks but Microsoft are known to revert things after an update. This could save me a bit of time. Thanks

I've ran this and there were two things I hadn't done. The USB controller power saving ( I thought I had so maybe got reverted)  and network adapter.

One other thing showed and that was power plan. I have mine set to ultimate but it still wanted to switch to high performance/balanced. Would that be better than ultimate power plan?

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.

More watts used and a hotter cpu. Depending on your usage it may be insignifacant or a little bit more power used. Also depends on the cpu and if you have iyour computer on all the time or only when in use.

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.

I would not add these. They are not related to the specific audio issues taken care by this tool. Adding this kind of stufff will quickly blow it up with hundreds of irrelevant settings, making it cluttered, bloated and similar to other overblown stuff already existing.

Why adding this setting when it does not change audio latency in a reproducable way? See above. Keep it simple!

Same. But let's see what the author thinks.

Mine are since at least 10 years that the setting doesn't matter anymore. Changed architectures in chipset, CPUs and Windows might be the reason.

Regarding power plans: after applying the Vilm Care changes one should have the opportunity to save this power plan under a custom name, directly within the app.

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.

Thank you, Ramses. Your reply was so thorough that I needed some time to think it through properly.
Before responding to each point, I want to share one of Vilm Care's core principles: democratizing good working environments and technical knowledge. The tool is designed so that even users who aren't comfortable with PC internals can use it safely. Because of this, it takes a somewhat conservative approach by default. With that in mind:

1. Great idea, and something I've been thinking about as well. A quick way to copy your system specs to clipboard as plain text, so you can easily share it anywhere. This will be in the next update.

2. Thank you for raising this. I agree that showing "unoptimal" to a user who already has Ultimate Performance active isn't right. The default Optimize tab will continue to recommend High Performance as the baseline, but I'm planning to handle higher-tier plans properly, likely in an Advanced tab where users can apply or recognize those plans.

3. Appreciated. Given the principle I mentioned above, I need to think a bit more about whether these two settings belong in the default Optimize tab or in a more advanced section.

4. Agreed.

5. BIOS guidance has been one of the most challenging areas. The options vary enormously depending on Intel/AMD, motherboard manufacturer, and generation. I'll need to research and organize the suggestions you've shared carefully. In that process, the knowledge and legacy from experienced users like yourself will be an invaluable reference.

6. The final one, and perhaps the most important. This is something I'm genuinely excited about for a future major update. Windows 11's CPU scheduling in particular doesn't always seem ideal for audio work. I can imagine something like a "Work Mode" that, once enabled, prioritizes key processes, potentially helping users without high-end PCs achieve a more stable workflow. I've read through your Process Lasso blog post carefully, and the content is truly exciting. However, this area needs to be handled with great care. It's sophisticated and potentially risky, so it will take time.

Thank you for such a detailed and generous reply, Ramses. Your work on computer audio optimization has been a resource I've learned from, and I'm glad Vilm Care could be of some help in return. And being added to your blog, that truly means a lot.

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

Yes and no. I do not run a DAW or any demanding SW, but my TaskManager shows: 230+ running processes using almost 2900 threads.... I do not think that any home PC has 2900 cores... So, background processes may easily share CPU core with a DAW, even if one has, say, 32C/64T....

But, you are right, that because there may be plenty of cores, background services may be spread among them and so cause less load on particular core.... But still, when one approaches the limits of computer, optimizing may play its role....

Certain video decoders and encoders get installed/updated via Microsoft Store so disabling might not be the best suggestion for people that do video work.

https://devblogs.microsoft.com/windows- … de-part-3/

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

Over here it's shopping even on holidays

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.

v1.2.0 is out! This update adds optional advanced options that users can choose to apply.
And some other things

Question on the two new nVidia settings: wasn't the most efficient workaround  a special tool that disabled the power saving of the nVida card? If so can this be added here, or does it require an external tool? In that case it would at least be helpful to mention it.

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.

Hi everyone, looks like a great discussion has been going on here!
These conversations on the RME forum genuinely help me a lot, every single time. Thank you, as always.

Regarding the Nvidia Low Latency option, I think I was a bit too quick to label it as Optimal/Unoptimal. I still believe it can bring positive changes in certain scenarios, but I agree it should be treated as a neutral option.
I'm also considering adding the Powermizer-related option that MC mentioned. Or possibly replacing it with the "Maximum Performance" setting from the Nvidia Control Panel (for a safer optimization approach).

To be honest, I'm thinking about to add nvidia control panel only for some reasons. The powermizer(registry) one is quite tough for this program's purpose. I need to consider more