Tuning the Vista Multimedia Class Scheduler MMCSS

Hi Jules,
I’m Ralf from germany (sorry for my english) and since a couple of years I’m a lonesome tracktioneer beside the mainstream. There is no other tool for creative recording that could better work for me.Thanks to you!!!

Today I run T3 under Vista SP1 and there were a lot of problems with audio data and MIDI-timing. The later the windows and hardware driver updates the bigger the problems.
I am programmer for hardware and so I looked out for the reason with my hardware measurement.
On my well tuned DAW the problems occured randonly and any software benchmarks gave no results for the reason.

Now I found a way to let T3 run better than ever. And any other application that do’nt use the Microsoft Multimedia Class Scheduler of course.

Here are the main changes I saw:
MIDI MTC synch: works!
Latest ASIO driver: no cricles and crashes again!
Lowest Latency settings: no random crashes again!
Lots of VST (in your genious Racks with chaining and all the tricks): works!

And all with only one registry change:

HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness

Default value: 20 (killing your non-MMCSS-optmized audio streaming applications :twisted: )
Range: 20 … 79
changed by: any application, persistent
My DAW (TOSHIBA TECRA S10-W , VISTA SP1,T3,ECHO AUDIO ASIO 4.8, Yellow Tools Indie, many VST(i), lots of outboard MIDI): 79

The value defines the percentage of kernel cpu ressources reserved for non-MMCSS-applications.
You can optimize the cooperation between new designed VISTA-applications like the latest ASIO drivers, soundcard drivers and on the other hand older XP-optimized applications like Tracktion, many VST and VSTi.

some remarks:

  • 20 percent as the default value is quite funny if you run applications that don’t use MMCSS!
  • The MMCSS controlles the kernel layer DPC, so you do not see this at any software benchmark. Measurement has to be a class higher to get any results, you know.
  • You can test any effect for a test on a well tuned DAW by controlling the ASIO driver buffer counter. A random underrun means that the value is too low, randomly overruns means the the value is set too high.
  • If nothing appears, make sure the value isn’t reseted by another application!
  • I don’t know wether restart is realy neccesary after changing!

I think everybody working with audio appications should remember this.
Maybe you’ll get a lot off mysterious crashes fixed!

Here’s the Microsoft resource:
http://technet.microsoft.com/en-us/magazine/2007.0 2.vistakernel.aspx

Here’s a tool for your experiments (even for all the MMCSS features):

Have fun and good results!
Best regards from germay

Thanks, interesting and scary stuff!

Oh, sorry. I certainly did not scare you! :slight_smile:
I suggest that we can positively influence the effect of the planner to applications which do not use it. With few side effects to be expected in powerful modern pc.
Test it out, it can get broken anything. You can only win.
Best regards

Very interesting indeed.
A short search lead me to this link :
An Audacity source code excerpt where things seem to have been done properly (see functions MMCSS_activate() et setupAVRT())

Interesting - I didn’t know such a function existed. It’d be easy to try out by adding to the WASAPI code, at WASAPIAudioIODevice::run():

[code] void setMMThreadPriority()
DynamicLibraryLoader dll (“avrt.dll”);
DynamicLibraryImport (AvSetMmThreadCharacteristics, avSetMmThreadCharacteristics, HANDLE, dll, (LPCTSTR, LPDWORD))
DynamicLibraryImport (AvSetMmThreadPriority, avSetMmThreadPriority, HANDLE, dll, (HANDLE, AVRT_PRIORITY))

    if (avSetMmThreadCharacteristics != 0 && avSetMmThreadPriority != 0)
        DWORD dummy = 0;
        HANDLE h = avSetMmThreadCharacteristics (_T("Pro Audio"), &dummy);
        if (h != 0)
            avSetMmThreadPriority (h, AVRT_PRIORITY_NORMAL);

void run()

(it’s also need Avrt.h adding to the includes)

…I’ve no time to actually try this today - anyone fancy having a go and seeing if it improves things?


I was looking at the Wasapi code and bumped into avSetMmThreadCharacteristics and "Pro Audio". So I looked at the msdn doc for this function.

In the remarks section is indicated:

When the task is completed, call the AvRevertMmThreadCharacteristics function.

So maybe this revert call should be added at the end of the Wasapi thread?


Well, the thread exits and is destroyed at that point, so changing its priority beforehand wouldn't serve any purpose, would it?

This part, i.e. setting MMCSS properties, has been in JUCE since waaaaay back, and I don't see the change. Am I missing something ? :)