Issues with Sonar's MMCSS implementation

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.

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.

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! :)

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.

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?

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'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]

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:

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.

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.

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?

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