Here is my complete and indeep technical analysis about the source of the RME/Live related problems which I gave to RME after testing two beta-testdrivers provided to me. Anyone not interested in the technical bla should just skip this whole post, all necessary informations were already provided earlier.
Ableton Support/Developer should read this post just in case they still have no clue about the source of the problem other than: Turning Multiprocessor Support off
fixes the problem.
-*-
In any case MMCSS should be disabled in RME's driver, because it leads to serious troubles with several different DAWs because of two reasons:
1. RME driver forcing its own priorisation scheme on DAW = big time Multiprocessing (MP) troubles
a) Ableton Live is affected most by this, but other DAWs get into troubles as well. When you activate MP in Live it creates two additional threads (on a 2 Core CPU) that run at HIGHEST priority (15 when Live is run as "Normal", 31 when Live is run as "Realtime"). Seemingly Live's MP mechanism is very much optimized for having these two additional thread run at the very same priority as the ASIO/driver thread. Unfortunately RME's current driver is forcing a priority of 26 on its ASIO thread, making it higher than the other Live audio threads. That leads to serious dropouts even with only one single audio-clip playing as soon as you turn on MP in Live.
The problem can either be circumvented by changing Live's priority to "Realtime", because that turns all MP threads and the ASIO thread to the same priority of 31, or you can simply turn of MMCSS via Vista's Services and thus force RME's ASIO thread back to the same priority 15 that the MP threads use.
b) Reaper is having less of a problem with RME's driver priorities as long as you don't use "Synchronous FX Multiprocessing". By default it's MP threads use a lower priority (Base priority 10 with dynamic priority upto 13) than the ASIO and thus seems to be optimized for that scenario anyway. So it doesn't matter to Reason wether RME's ASIO thread uses priority 15 or 26 or whatever as long as the ASIO thread's priority doesn't fall below Reapers MP threads and Reapers "Thread Behavior" isn't set too aggressive.
Things become more problematic once "Synchronous FX Multiprocessing" is turned on though. Reaper then creates one thread with a highest priority of 15 and needs that one thread to be at least the same priority as the ASIO thread. With RME's ASIO thread being of the higher priority 26 dropouts can be experienced under heavier load. So again you either need to turn Reaper to "Realtime" and thus force both threads to the same priority 31 or turn off MMCSS to get RME's ASIO thread back down to 15.
c) Sonar works entirely different compared to Live and Reaper. When turning on MP it will only create one single additional thread to its already high number of threads and doesn't seem to care much for RME's ASIO priorities. Additionally you can turn on Sonar's own MMCSS implementation which will only affect Sonar's own MP thread though and doesn't seem to work with MP anyway.
d) Cubase and other DAWs very likely use their very own MP and priorisation scheme. In any case it should be left to the DAW to decide upon that and not the driver. It's ok to set a different default priority in the driver as long as the DAW is still allowed to change it.
2. Principle problems of MMCSS - there is no light without shadow
The default behavior of MMCSS is to boost a Multimedia process for 8 ms to realtime priority (16-31) but then lower it to idle priority (1-7) for 2 ms. Additionally a process needs to chose kind of "task" is to be fulfilled by MMCSS, audio work below 10 ms latencies is meant to use the "Pro Audio" task. While initially MMCSS looks like a very good idea, boosting multimedia processes that need high priorities over background processes, the fact that there is a short time of lowest priority is a problem for realtime audio applications with low audio buffer sizes. That has nothing to do with Multiprocessing even when turning off MP will ease the situation (the reason being that half the CPU is left free and that current drivers/DAWs create around 200% additional overhead for pure audio-playback when MP is turned on).
Unfortunately RME's MMCSS implementation seems to be flawed in that it lowers the priority of the ASIO thread far too often and easily. Like mentioned before I suspect that maybe the wrong "task" has been chosen (like "audio" instead of "pro audio"), but frankly I don't have no idea about the specifics of these things (I'm no coder anyway). Cakewalk Sonar's MMCSS implementation is considerably less prone to system load (tested with over 50% load from Explorer.exe which runs at priority
, but will also drop performance if a constant full scale load is present (Prime95 using all available CPU at priority 1).
On a normal pro audio PC (with no constant high load background process running) MMCSS should provide a DAW with just the necessary edge for smooth operation without need to switch the whole DAW process to Realtime (which would leads to serious problems once the DAW hangs or gets stuck in a loop). The main advantage of using MMCSS over "Normal" to "Highest" priority on Vista comes to play when using AERO, because Aero/DWM's process uses threads at priority 15 itself and thus collides with audio/ASIO threads regulary. The main advantage of using MMCSS over "Realtime" priority is that the system is still useable and responsive even when the DAW hangs/crashes/loops endlessly.
There is a Registry that is meant to control the ratio between realtime and low priority of MMCSS, but I didn't experience any much differences when changing it.
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile"
This key contains a REG_DWORD value named SystemResponsiveness that determines the percentage of CPU resources that should be guaranteed to low-priority tasks. For example, if this value is 20, then 20% of CPU resources are reserved for low-priority tasks. Note that values that are not evenly divisible by 10 are rounded up to the nearest multiple of 10. A value of 0 is also treated as 10."
Conclusion: It seems that Audio drivers should not implement MMCSS themselves, or maybe RME just did it wrong (compared to Sonar at least). Priority and MP control should stay in the hand of the DAW which knows best how to handle its own threads. I suggest for RME to remove MMCSS from their Vista drivers or have another look if it's performance could be improved without making DAWs struggle against it (I heard from Ableton that they will try to change their own MP priority behavior to deal with the RME driver).
to be run under the newest/current OSes.
