Issues with Sonar's MMCSS implementation

Hey everyone!

I have recently been very busy helping RME to fix bugs with their Vista driver implementations, because performance with my main DAW Ableton Live was unuseable when Multiprocessing (MP) was enabled and even without MP performance issues were noticeable with both Live and Reaper. During my course of testing I added the trial of Sonar 7 to my arsenal and came up with some issues around MMCSS that might interest you Sonar user.

This is taken from my reports to RME and Ableton and thus concentrates on Live first. Live has specific problems when using MP support if any of its audio-threads have a different priority than the others. That means that when the ASIO driver's thread is pushed by MMCSS while the other MP threads are not then considerable dropouts occur. Since the issues mentioned in these parts may affect users of all DAWs you might find them interesting, too. The last part explicitely describes issues/bugs with the MMCSS implementation of Sonar (trial) that I have stumbled upon.

So here come the results of RME's latest driver 2.95:

Unrelated to the DAW being used, MP support being used or wether RME's driver implementation or Sonar's implementation of MMCSS is used MMCSS gets into troubles with low buffer sizes whenever there is constant system load, even if that happens at lowest priorities. The higher/more constant the load the higher/more constant the audio-dropouts. That is because of MMCSS behavior to fall back to lowest priorities regulary, which also regulary turns the state of the audio-threads to READY (aka non-working). This shouldn't affect normal working conditions, but the combination of both RME's and Sonar's MMCSS proves to be fatal (see below)!

1. Ableton Live, MP on, 64 samples, 1 track playing (so MP thread effectively not used)

a) RME MMCSS off, 50+% CPU load by Windows Explorer



I even checked with Prime95 running full load in the background, same picture. As long as no other priority 15 process/thread is colliding with Live's threads (like Process Explorer when set to Highest) there are no dropouts whatsoever.


b) RME MMCSS on, 50+% CPU load by Windows Explorer



Dramatically different picture, even the slighest load will lead to dropouts and CPU load of RME's ASIO thread rises considerably. Gets even worse when more than 1 audio track is playing so that Live's MP thread starts working concurrently. Like mentioned before two reasons seem to at work here, a) RME ASIO-thread priority being higher than Live's MP threads' priority and b) MMCSS priorisation problems. The 50+ CPU load by Windows Explorer was generated by exploring a bug of Vista's Explorer (wrong type of URL link in Start Menu) and only chosen to demonstrate the problem in a reproduceable and somewhat extreme manner. Anything that produces higher load will produce audible dropouts, even if it's just occassional.


2. Cakewalk Sonar, 64 samples, 1 track playing (so MP thread effectively not used)

a) RME MMCSS off, Sonar MMCSS on, 50+% CPU load by Windows Explorer



As you can see I was wrong in my former post that Sonar doesn't use MMCSS if MP support is turned off. It does use MMCSS and it does so by changing the ASIO driver thread's priority. I couldn't see this before, because when MMCSS is turned on in RME's driver then the RME setting supersedes Sonar's when analysed via Process Explorer (see below under b)).

When MP support is turned on in Sonar then a second thread is created that also uses MMCSS with the same Base priority of 1 and Dynamic priority of 24. This runs pretty flawless as long as no constant system load is produced by background tasks (see above).

There seems to be a bug within either Sonar or the RME driver though. After starting Sonar the RME ASIO thread starts with a priority of 15 (MMCSS in RME driver turned off, MMCSS in Sonar turned on), after opening a set it changes to MMCSS priority 24. But after using and closing the Audio settings dialog in Sonar (even when nothing is changed and the dialog is closed by CANCEL) the priority of RME's thread changes back to 15 and Sonar's MMCSS for that thread is turned off, while Sonar's own MP thread keeps using MMCSS (checked back by ears, no more MMCSS related dropouts by RME ASIO thread once that happens). Only restarting Sonar and loading a set will reactivate MMCSS on the RME ASIO thread again.


b) RME MMCSS on, Sonar MMCSS on, 50+% CPU load by Windows Explorer



This is the worst case scenario. Obviously Sonar's MMCSS and RME's MMCSS fight each other with RME's MMCSS priorities superseding Sonar's. Even the slighest load will lead to dropouts (like simply turning on Aero or clicking things on the GUI). I take this as a proof that RME's MMCSS implementation should be turned off by default while but the nice manual switch option of 2.95 could remain. :)

Turning off either Sonar's or RME's MMCSS eases the problems instantly, but using Sonar's MMCSS is still to be prefered. That is because with RME's MMCSS the MP audio threads of Sonar will only use non MMCSS priority 15, which may lead to priority related troubles like with Live.

Conclusion: Like stated before, the DAW should know best how to handle its own threads and priorities. Having a switchable option in RME's drivers is nice, but the default behavior should be to have MMCSS turned off on driver level. My hope is that DAW developers will incorporate MMCSS into their DAWs sooner or later.

I checked Sonar's MMCSS with all 5 audio-interfaces at hand (RME FF, NI Kore, Creative X-Fi, M-Audio Audiophile 2496) and there seem to be issues with all of them. While the current RME driver and the X-Fi driver switch off MMCSS (back to priority 15) only when accessing Sonar's Audio settings, all others even switch back by simply starting playback.

Interestingly the X-Fi driver is the only one not showing aggressive dynamic priority behavior in Reaper. That means that all other drivers will use a dynamic priority of 15 (with only seldom dropdowns to 14) even when a Normal priority of 8 is manually set in Reaper, while the X-Fi driver will stay around 8 (mostly 9, with peaks upto 13).

Additionally the latest RME driver 2.95 does not seem to save the MMCSS setting over a Windows Restart, but default back to MMCSS being turned on (at least I remember having it set to off before the last reboot, but I will check again).

Hi Timur,

Thanks for the detailed post. I actually meant to warn people about this, since I noticed this issue with the Echo drivers as well. There is absolutely no need to turn on MMCSS at the driver level when using SONAR with MMCSS enabled in Options | Audio | Advanced.
In Vista a thread can register itself with MMCSS only ONCE and it fails when you try and do this multiple times.
Its possible that when a second MMCSS registration is attempted, the failure then causes MMCSS to be turned off completely for that thread.

In SONAR with ASIO or other driver modes, we automatically register all relevent threads to use MMCSS so there is no need for a driver to do this. I'm not sure why driver vendors are setting thread priorities for MMCSS since this is really a host function. You should make sure that MMCSS is NOT enabled at the driver level or bad things <TM> will happen :-)

thanks,
Noel

ORIGINAL: Timur


Turning off either Sonar's or RME's MMCSS eases the problems instantly, but using Sonar's MMCSS is still to be prefered. That is because with RME's MMCSS the MP audio threads of Sonar will only use non MMCSS priority 15, which may lead to priority related troubles like with Live.

Conclusion: Like stated before, the DAW should know best how to handle its own threads and priorities. Having a switchable option in RME's drivers is nice, but the default behavior should be to have MMCSS turned off on driver level. My hope is that DAW developers will incorporate MMCSS into their DAWs sooner or later.

My pleasure, Noel!

RME already made a beta driver available via forum (that stillt defaults to MMCSS being turned on after reboot) and announced to implement an optional switch into all its driver range (that will keep MMCSS setting over reboot). So with RME the issues are solved I guess.

Regardless of this I should emphasize again that the issues of Sonar losing MMCSS priorities when starting playback or accessing the Audio settings is happening when MMCSS is not implemented in the drivers. All but RME's drivers that I tested do not use MMCSS at all, and the RME driver behaves like this after turning off MMCSS. So there seems to be a problem within Sonar. This cannot only be seen via Process Explorer, the MMCSS ASIO thread gets killed and new threads at fixed priority 15 are started, but can also be made audible. Sonar's MP thread is not affected by this but stays at its MMCSS settings of 1/24.

Noel, as the expert that you are, maybe you could answer me three thread/priority/performance related questions?

1. Do low-latency, multiprocessing DAWs benefit from Vista's "better" thread scheduling (especially knowing that all MP related audio threads share the same priority)? Or doesn't it matter to the DAW's thread-managment anyway even with XP's flawed scheduling?

Before Vista thread scheduling was handled on a set interval timer that lead to "unfair" distribution of CPU time among threads even if their are set to the same priority.

Before Vista ("Leerlauf" translates to "Idle"):


Vista:


2. How badly do DAWs suffer from MMCSS' default behavior to lower the audio-threads priority down to 1-7 for 2 ms after each 8 ms high priority interval?

I found this to be a realistic possible problem with low buffer sizes and tried to influence Vista's default behavior by using the "SystemResponsiveness" registry key. But altering that key does not seem to show any impact, neither good nor bad, regardless of wether its set to its minimum of 10% or maximum of 100%.

In theory I find MMCSS much preferable to setting the DAW's Base Priority to Realtime. The latter promises the best possible performance, but comes with the risk of the DAW locking the whole system with no chance but resetting the PC if the DAW should ever get locked in an overload loop. MMCSS on the other hand will always enable you to hit STOP or at least kill the DAW process quickly, at least in theory.

3. Will/Would DAWs benefit from the use of Vista's harddrive I/O priorisation?

In theory it seems to make sense to make DAWs use high I/O priorities for their streaming harddrive activity, especially if samples/samplers are used for playback. Evenmoreso it seems to be natural to use Vista's feature to "reserve bandwidth" in order to maintain a gapless stream of uninterrupted data-flow, unhampered from other processes.

Thanks in advance for any insight! :)

ORIGINAL: Timur

I checked Sonar's MMCSS with all 5 audio-interfaces at hand (RME FF, NI Kore, Creative X-Fi, M-Audio Audiophile 2496) and there seem to be issues with all of them. While the current RME driver and the X-Fi driver switch off MMCSS (back to priority 15) only when accessing Sonar's Audio settings, all others even switch back by simply starting playback.

Interesting read.. :-)

So what are the results with MMCSS Off in SONAR.. ?

The reason I ask, is that I have never been able to achieve a quantifiable improvement with it on.., others mileage may vary :-)

Peace

V:

MMCSS doesn't affect audio performance any much unless other processes of high priority conflict with the Sonar. Without MMCSS Sonar already uses the highest possible non-realtime priority of 15 for its audio/midi threads. The main use for MMCSS is that it elevates Sonar's audio thread's (not midi or anything else) priorities even higher above all of Windows' system-services and all other background running processes.

That's especially important if you enable Aero (3D Desktop), because the Desktop Windows Manager (DWM) of Vista runs its own threads at priority 15 as well. Using AERO without MMCSS is like turning Sonar's GUI (drawing) to highest priority and thus putting it on the same level as audio and midi processing. The good thing about Aero/DWM is that it draws everything efficiently summing up all applications and windows (including VSTs) into a single thread with little load where the sum of many independently drawn windows would produce higher load (especially if those use inefficient drawing methods). But CPU load is by 2-3% higher on my system (A64 X2 @2800 mHz) with Aero enabled than without to begin with.

MMCSS does not help against DPCs from (badly written) device-drivers (like wireless network interfaces), because DPCs always supersede thread priorities as far as I know. Turning Sonar (any DAW) to "Realtime" can lead to even better performance than using MMCSS, because MMCSS regulary switches to lowest priorities and Realtime priorities for audio plus midi threads are pushed to the highest possible priority 31 while it's GUI/program main threads run at 24. But don't ever dare to overload Sonar or your ASIO driver while on Realtime, you have little chance to get it back from hanging else than reseting.

Windows Service running at HIGHEST priority (15), these compete with audio, midi and sonar's GUI/main program threads, MMCSS priorizes audio and midi over these.

Csrss.exe (usually very low load)
DWM.EXE (no load with Aero is disabled, else usually low load increasing with dynamic GUI drawing elements)
Winlogon.exe (usually no load)
Wininit.exe (usually no load)

The only one of these that can be turned off is DWM.EXE (simply turn off Aero). Additionally there are a couple of other services running at priorities 10-13 which may also compete with Sonar/any DAW. And a whole lot of services running at normal priority (8-10) that at least want to have their share once in a while as well. MMCSS uses two threads with very low load itself, with one thread running at priority 27.

Parts of EXPLORER.EXE are also running at priority 15, notably one audio-driver thread which I suspect to be responsible to output system-sounds. There are also at least two bugs that can lead to Explorer using over 50% of CPU load (even if usually only for a short amount of time). MMCSS will supersede any Explorer activity and thus can help to stay out of performance problems when clicking around Windows during DAW activity.

By the way, Windows Defender and Sidebar are running at Normal priorities (8-10), so don't worry too much about them. They do use normal harddrive priorities though, so if they access files while you are streaming lots of samples from disc they might have an impact.

Superfetch runs as normal priority with LOW disc I/O priorities, so there isn't that much to worry about. But since Superfetch keeps accessing the harddrive you might want to turn it off in a recording room in order to keep the noise down.

Regarding 1, yes better thread scheduling definitely matters as long as "better" means that the OS's load balancing of threads is improved. As Mark Russinovich describes here, Vista has some improvements in this area. In XP a thread being denied its due timeslice could definitely lead to a glitch or a premature dropout in SONAR since we have N time critical threads running simultaneously.

Regarding 2, my understanding was that this behaviour only applied when the system was in a high load situation and there were insufficient CPU resources for the other threads to run. In that scenario its understandable. However AFIK the SystemResponsiveness value is gated to a hard limit of 10%, which is why you observed that changing it lower won't help. We objected to this assumption in the early Vista design, since on a DAW you might want to squeeze even the last few %'s out of your CPU if thats what you really needed. On XP you can do this, without big brother deciding that you had enough.

Regarding 3, the harddrive prioritization is not a huge issue for us since we have our own disk caching that is more suitable to audio processing anyway. In fact our disk reader thread is not a time critical thread since we don't want it interrupting the realtime audio processing threads. Disk processing is most efficiently done synchronously anyway due to the nature of hard drives.

ORIGINAL: Timur

1. Do low-latency, multiprocessing DAWs benefit from Vista's "better" thread scheduling (especially knowing that all MP related audio threads share the same priority)? Or doesn't it matter to the DAW's thread-managment anyway even with XP's flawed scheduling?

2. How badly do DAWs suffer from MMCSS' default behavior to lower the audio-threads priority down to 1-7 for 2 ms after each 8 ms high priority interval?

3. Will/Would DAWs benefit from the use of Vista's harddrive I/O priorisation?

Hmm so we don't turn on MMCSS again after you open the audio settings dialog? It shouldn't be doing that.
The ASIO driver is restarted after the dialog is closed so a new thread is created at that time. The new thread should be getting set to MMCSS priority again. I will look into this. I'm curious if you also see this behaviour in WDM mode or its only in ASIO mode?

ORIGINAL: Timur

My pleasure, Noel!

RME already made a beta driver available via forum (that stillt defaults to MMCSS being turned on after reboot) and announced to implement an optional switch into all its driver range (that will keep MMCSS setting over reboot). So with RME the issues are solved I guess.

Regardless of this I should emphasize again that the issues of Sonar losing MMCSS priorities when starting playback or accessing the Audio settings is happening when MMCSS is not implemented in the drivers. All but RME's drivers that I tested do not use MMCSS at all, and the RME driver behaves like this after turning off MMCSS. So there seems to be a problem within Sonar. This cannot only be seen via Process Explorer, the MMCSS ASIO thread gets killed and new threads at fixed priority 15 are started, but can also be made audible. Sonar's MP thread is not affected by this but stays at its MMCSS settings of 1/24.

ORIGINAL: Timur

MMCSS doesn't affect audio performance any much unless other processes of high priority conflict with the Sonar. Without MMCSS Sonar already uses the highest possible non-realtime priority of 15 for its audio/midi threads. The main use for MMCSS is that it elevates Sonar's audio thread's (not midi or anything else) priorities even higher above all of Windows' system-services and all other background running processes.

That's especially important if you enable Aero (3D Desktop), because the Desktop Windows Manager (DWM) of Vista runs its own threads at priority 15 as well. Using AERO without MMCSS is like turning Sonar's GUI (drawing) to highest priority and thus putting it on the same level as audio and midi processing. The good thing about Aero/DWM is that it draws everything efficiently summing up all applications and windows (including VSTs) into a single thread with little load where the sum of many independently drawn windows would produce higher load (especially if those use inefficient drawing methods). But CPU load is by 2-3% higher on my system (A64 X2 @2800 mHz) with Aero enabled than without to begin with.

Hey Timur,

I'll leave all of the thread priority discussion to you and Noel, I am barely treading water there... :-)

What is of most interest to me, and to the majority is not the under hood mechanics, but the end result/benefit, and from my understanding of what you have explained, there is little to no benefit in MMCSS , unless you are using Aero. Interestingly, the first thing that many of us switch off when optimising Vista for Audio use is the Aero interface , which proved quite detrimental in all of my personal testing, especially at lower latencies. This experience does not hold true with your summation of the benefits of Aero, which btw has been repeatedly postured by Microsoft from the get go, but has never really panned out in audio application.

This leads me back to the original question.., taking Aero out of the equation, is there any change in behaviour /performance with MMCSS off in SONAR ?

I am sorry if you answered that directly, I must have lost it in the mix... :-)

V:

I think you will see benefits even if Aero is off but you have another application or background task that is competing for resources. In simple terms all MMCSS does is try and guard against unwanted scheduler interruptions. Its important to note that it cannot get you extra performance if you don't have any competing background tasks.
In the original Microsoft demos for MMCSS they had windows media player playing something while they ran stress (a program that hogs CPU resources). In the test audio kept streaming without glitches although the CPU was being severely taxed.
This is a somewhat simplistic model compared to what a DAW does obviously, but it does buy back some stability under load. On a well tuned DAW you hopefully don't have too many background tasks that suck up CPU load :-)

I'm sorry to butt in, and I understand very little of which you folks are conversing in writing so eloquently. I am just flabbergasted that Noel is having a technical discussion on the forum on Sunday afternoon/evening. Unreal. Cakewalk rocks. Bye.

ORIGINAL: Noel Borthwick [Cakewalk]
This is a somewhat simplistic model compared to what a DAW does obviously, but it does buy back some stability under load. On a well tuned DAW you hopefully don't have too many background tasks that suck up CPU load :-)

I work for a game company, and at any given time I have Sonar, Audition, Excel, Word, Firefox running a java applet, Outlook, Jabber, Quicktime Player, and Alienbrain (version control) running at the same time. Plus, all of the connections to our Samba shares. It's just not feasible to have a dedicated DAW, or to shut down and restart all the apps when I need them--since I need them just about all the time.

So whatever you can do to keep Sonar at the top of the scheduler heap is greatly appreciated.

ORIGINAL: Noel Borthwick [Cakewalk]

I think you will see benefits even if Aero is off but you have another application or background task that is competing for resources. In simple terms all MMCSS does is try and guard against unwanted scheduler interruptions. Its important to note that it cannot get you extra performance if you don't have any competing background tasks.

Hey Noel,

Thanks for the clarification.. :-)

That is much in line with my own experiences on a dedicated DAW, where as you have noted, background tasks are at a minimum..

Peace

V:

Sorry for not reporting back earlier, but I was rather busy and since I'm not working with Sonar (nor Vista yet because I need to make sure software vendors fix their bugs first) it took some time to fire up the system for testing again.

ORIGINAL: Noel Borthwick [Cakewalk]

Hmm so we don't turn on MMCSS again after you open the audio settings dialog? It shouldn't be doing that.
The ASIO driver is restarted after the dialog is closed so a new thread is created at that time. The new thread should be getting set to MMCSS priority again. I will look into this.

Also have another look at what Sonar does when hitting the PLAY button! Like reported earlier Sonar switches off MMCSS on 3 out of 5 drivers/interfaces on my system by simply hitting PLAY without even going into the settings dialog.

I'm curious if you also see this behaviour in WDM mode or its only in ASIO mode?

Unfortunately my 15 days trial expired meanwhile so you have to look into this bis yourself. :P

Best wishes and success for your product. I'm going back to fight with Ableton support over their list of unidentified (hence unfixed) issues.

Ah, I forgot to mention two things:

1. RME included an optional switch to turn MMCSS on/off on driver level. By default it is switched off now, so it shouldn't get into troubles with Sonar anymore.

2. Ableton Live's latest beta update 7.09 switches MMCSS in the RME driver off regardless of what the mentioned optional switch is set to. Maybe Sonar should do that as well once MMCSS is switched on in Sonar to make sure that the driver's MMCSS implementation doesn't supersede Sonar's.

What a fabulous thread, I know some people are moaning that the forum is full of idiots, (myself probably included) but I think all forums have noise, but this is what makes the forum great, Sonar guys coming on and having real honest converstations about the product. I know from one of my actually serious posts around the Liquid Mix and how helpful Noel was on that.

Do you think Timur realizes that Noel is the big Cheese, and he was willing to give up his Sunday afternoon to deal with someone who is only using the demo, awesome, maybe if he did know he would not be going back to Ableton :)

Cheers Noel keep up the good work.
G

Hehe, don't worry, I do know about Noel (read his interview article some months ago when informing myself about Vista). Besides that it was me supporting Sonar eventhough I'm only using the demo, not vice versa. ;)

I'm sure Sonar is a nice product, but 1. I prefer cross-platform software (Windows + OS X) and 2. Live is a whole different working tool. So once I need a better software for arrangement it's most likely gonna be cross-platform Cubase unless Sonar plans to do a OS X port anytime soon.

Once I've done a fresh installation of Vista I will run the Sonar demo again to check for the WDM thing and also some Midi related crash that I once produced.

Thanks again, Noel, for the quick and educated reply.

Fair enough Timur

Cubase might be cross platform, but that just means it sucks on both :), that was toungue in cheek and not meant to start a flame war.

I just find it amusing that sometimes cross platform operability comes higher than anything else in terms of choosing software. There was me thinking useability, tools and features were important :)


G

Well, since everything about the issues is said now, I think we can savely go somewhat off-topic. ;)

Cubase 4.1 (note the .1) should be very useable and a good complement to Ableton Live for arrangement and Midi features. Don't worry though, I am checking several other DAWs as well, such as Reaper and Logic. Unfortunately there is no trial of Cubase, but to be frank, the 15 days trial of Sonar is such a short period of time for a busy man that it's near useless. I prefer the trial/payment model of Reaper over everything else.

I am also aware that Cubase is said to be quite bug-invested, but judging on the changelogs by Steinberg they seem to handle bug-fixing professionally. My experience with Noel's direct and quick support via this thread are surely very good though. In the end, if I find myself buying Cubase and it does not deliver stable and bug-free/fixed functioning then I can always return it and ask for a refund.

Portability and independence of an OS aka cross-platform support are not to be under-estimated. I'm working on a Windows PC while my collaborateur works on a Mac. Also with modern Mac's using an Intel basis the ability to chose between whichever OS offers best performance and stability at a given time is very useful. What if the next Windows/OS X Update spoils your DAW fun? Just switch to the other. :)

Maybe you can point me to what makes Sonar stand out against Cubase or other DAWs as far as Arrangement/Mixing/Mastering and Midi features and also Combing go?

Hi Timur,

I investigated your issues and was able to reproduce them in SONAR 7. Thanks for bringing it to my attention.
I have made many enhancements to improve MMCSS performance in the future.

regards,
Noel

CHeer Noel

Hey Timur I used Cubase for years, and its not a bad DAW.

The things that have made me switch to SOnar and stay here are.

AudioSnap - this was hte biggie and its massively useful more intuitive and slightly more powerful than the warp feature etc in Cubase.
THe midi features now match Cubase since Sonar 7 and if like me you actually really liked the midi in Cubase, there is an option in Sonar which makes the midi tools mimic Cubase (they can also mimic Logic and other popular DAW's)
Midi Magnifier is very useful as is the Step Sequencer.

V-Vocal- I have used this extensively not on vocals but on guitar, you can get some really interesting effects if you sit and play around with it.

I really like the Convolution reverb that comes bundled as well, I keep coming back to it, its fabulous I prefer it to my bought Reverbs.

In terms of comping have you found the track layers option, this is really usefull when it comes to doing multiple takes, you can then very easilly edit the comps together either by cutting and pasting, or by using the handy mute tool. I tend to use a combinatio nof both I use the mute tool to create a rough scratch really quickly, once I am happy with it, I will then do the cutting and pasting and crossfades etc.

Clip envelopes is hugely usefil as it allows you very quickly to go through a track that has room noise, ie mic brush sniffing sounds etc, and remove them without having to cut the track into millions of clips and do lots of crossfades.

These are just some features of hte top of my head,Cubase has a lot of them but the way Sonar has implemented them just make them easier and more intuitive to my mind.

However this is purely a personal preference, and most of the people I work with are less bothered about OS and more about DAW, i.e I have more people ask me why I don't use PT than I do ask me why I use a PC, but then in the Uk and in the musical form I tend to work (urban). PC's are the preferred option becuase its a grass roots in the bedroom thign, and more people have access to PC's than MACS when they start, and then tend to stick with em.

IN your situation I can see why cross platform is important.

Regards
Gordon

Hi, Timur. One workaround to the Sonar mmcss issue that I've found which helps Sonar64 performance is to cut the "SystemResponsiveness" value in half. I found set to 20 decimal on my system and changed it to 10 decimal (0A). It's in this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile

Howard