All Live/Vista performance problems identified!
Hey, I don't think we should discuss these things in this thread. This is about Live's Vista and RME issues.dom wrote:Hi Timur,
As far as I understand you are the person in response for support, but I kindly ask you to meet in person next time I'm visiting Berlin. Too much went wrong with communications between Ableton representatives and me that mostly lead to no useful outcome.
Yes, quite inspirational, until I came back home and had to deal with Live's issues again and which. As I am writing this Live runs idle at 50% in the background doing nothing but heating up my room.Besides all the technical stuff: I hope you enjoyed a few great days in the sun last week and hope you're filled with inspiration!
hey guys, keep cool and have a smoke!
Timur, is it a must to produce your tracks on vista, especially if you are experiencing trouble with your setup and vista? And please do not refer to internal os prioritization mechanisms, this is only unneeded theory for making music with a computer. i don´t hear any difference in music whether its made with vista or xp. the problem with wista is that it has so many overloaded features in its kernel that its contraprductive to make music with. who needs graphics acceleration for a 2D application? i don´t need the extra features of an overblown NT system, the XP kernel is also based on the same kernel but it´s much more slimmer than the vista one. vista has so many features a daw will never require.
somtetimes i have the impression that you have more fun analyzing prducts than making music with a computer.
why don´t you accept the offer getting a full refund if you're not satisfied with live?
timur, don´t take this personal, I know you´re a good guy and helping people a lot, especialy when it somes to proper configuring a windwos based os.
i must also say that referring to some ableton representatives forum posts sometimes the company is a sorehead.
i realy think it´s their task/duty to make their piece of software able(ton)
to be run under the newest/current OSes.
but as always: software (and that includes OSes too) will never be perfect. but it will run in most conditions to have good results.
Timur, is it a must to produce your tracks on vista, especially if you are experiencing trouble with your setup and vista? And please do not refer to internal os prioritization mechanisms, this is only unneeded theory for making music with a computer. i don´t hear any difference in music whether its made with vista or xp. the problem with wista is that it has so many overloaded features in its kernel that its contraprductive to make music with. who needs graphics acceleration for a 2D application? i don´t need the extra features of an overblown NT system, the XP kernel is also based on the same kernel but it´s much more slimmer than the vista one. vista has so many features a daw will never require.
somtetimes i have the impression that you have more fun analyzing prducts than making music with a computer.
why don´t you accept the offer getting a full refund if you're not satisfied with live?
timur, don´t take this personal, I know you´re a good guy and helping people a lot, especialy when it somes to proper configuring a windwos based os.
i must also say that referring to some ableton representatives forum posts sometimes the company is a sorehead.
i realy think it´s their task/duty to make their piece of software able(ton)
to be run under the newest/current OSes.but as always: software (and that includes OSes too) will never be perfect. but it will run in most conditions to have good results.
No other piece of software shows the symptoms that Ableton Live shows on Vista, so I assume that these are problems of Ableton Live and not of Windows Vista. I have gone a great length to prove my points are valid and even worked into Ableton's hands by providing them with free and useful analysis data.
I don't want refund, I want reproduceable bugs to be acknowledged and fixed within reasonable timeframes. When I contact Ableton Support I expect knowledgeable answers that either help finding issues within Live or convincingly proof that the culprit has to be within my system-setup.
If a fix is not possible out of whatever reason I expect the known bugs to at least be acknowledged either personally (email) or publicy (news, readme, forum). That way I and other users don't have to waste time on trying to fix our setups hoping to get Ableton Live running properly when in reality that is not possible anyway because of issues within Live.
Now please Ableton, fix the bugs mentioned in this thread so that finally I can switch to Vista completely and then we can go on discussing the list of other outstanding Live related issues I am hoping to be supported with by those who get paid for that job.
I don't want refund, I want reproduceable bugs to be acknowledged and fixed within reasonable timeframes. When I contact Ableton Support I expect knowledgeable answers that either help finding issues within Live or convincingly proof that the culprit has to be within my system-setup.
If a fix is not possible out of whatever reason I expect the known bugs to at least be acknowledged either personally (email) or publicy (news, readme, forum). That way I and other users don't have to waste time on trying to fix our setups hoping to get Ableton Live running properly when in reality that is not possible anyway because of issues within Live.
Now please Ableton, fix the bugs mentioned in this thread so that finally I can switch to Vista completely and then we can go on discussing the list of other outstanding Live related issues I am hoping to be supported with by those who get paid for that job.
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).
-*-
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).
-
Machinesworking
- Posts: 11421
- Joined: Wed Jun 23, 2004 9:30 pm
- Location: Seattle
JUst a quick question, do you own any other major audio and MIDI DAW? Samplitude, Sonar, Cubase etc? When you say "No other piece of software", do you mean no other DAW? A large workstation will be more likely to show problems in a new OS, more likely than SoundForge etc.Timur wrote:No other piece of software shows the symptoms that Ableton Live shows on Vista, so I assume that these are problems of Ableton Live and not of Windows Vista. I have gone a great length to prove my points are valid and even worked into Ableton's hands by providing them with free and useful analysis data.
Just to be fair to Ableton, it's quite possible that the issues are not theirs. OSX and Audio Units had serious flaws out the door, and MOTU released Digital Performer with strict Audio Unit support, very clean code etc. Unfortunately plug in manufacturers had been writing code for Logic, which did not follow the AU spec accurately! I could see a similar set of issues regarding Sonar and Vista VS any company with less inside support.
Anyway, I feel you on the problems, hate little nagging bugs, and on that line I hope you're over at NI forums addressing Kore issues! My favorite, Performance presets are not save in Kore in a Live Set. You have to reload the Performance every single time. NI support took three different emails and phone calls before they even understood what I was saying, and acknowledged the bug..... waiting on the update is another story.........
I tested Sonar and Reaper, but that's not relevant since we are talking about GUI/graphic issues here, which is totally unrelated to audio or VSTs. Live's simply needs an awful load of CPU power to draw it's dynamic GUI elements (especially dynamic ones like meters) or when running in full-screen mode.
No other piece of software (regardless of being DAWs or anything else) does that and it happens on different hardware setups. Additionally I proved via Process Explorer that Live's Stack only shows graphic-driver relevant calls (see that Nvidia GetAtomIString thing) when the problems happen. It can be reproduced in less than 2 minutes and I guess any half-talented developer can easily trace it down via a debugger.
That doesn't mean it's easy to solve and I don't expect it to happen within days. Maybe something fundamental has even to be changed within Live's GUI. But that doesn't give Ableton right to ignore a known bug and serious OS compatibility issue for half a year (building on the premise that most people will blame Vista anyway and change back to XP)!
Sorry that I have to be so blunt, but my current conclusion about the quality of Ableton's support is: Nice package, little content. I am very willing to learn that I am wrong, but that should involve to get some solutions anytime soon for a whole couple of issues that I am waiting to be handled for quite a long time now.
No other piece of software (regardless of being DAWs or anything else) does that and it happens on different hardware setups. Additionally I proved via Process Explorer that Live's Stack only shows graphic-driver relevant calls (see that Nvidia GetAtomIString thing) when the problems happen. It can be reproduced in less than 2 minutes and I guess any half-talented developer can easily trace it down via a debugger.
That doesn't mean it's easy to solve and I don't expect it to happen within days. Maybe something fundamental has even to be changed within Live's GUI. But that doesn't give Ableton right to ignore a known bug and serious OS compatibility issue for half a year (building on the premise that most people will blame Vista anyway and change back to XP)!
Well, I'm waiting for half a year now for exactly the same reasons. My experience with Ableton's support has been a very mixed bag so far. People are generally nice and friendly and I guess we would like each other when meeting personally. But as you have witnessed yourself in this thread the chance to be blamed for hurting someone's feelings when reporting nuisances is higher than to get answers and solutions for the problem at hand. And when I have been given informations they sometimes have even been technically wrong. This can happen to anyone, but isn't a certificate about how knowledgeable support members are. I have experienced far worse with NI support to be frank, but also far better sometimes, especially when it comes to discussing problems until they are finally identified.NI support took three different emails and phone calls before they even understood what I was saying, and acknowledged the bug..... waiting on the update is another story.........
Sorry that I have to be so blunt, but my current conclusion about the quality of Ableton's support is: Nice package, little content. I am very willing to learn that I am wrong, but that should involve to get some solutions anytime soon for a whole couple of issues that I am waiting to be handled for quite a long time now.
+ 1
and the "if you don't like our support, we'll give you your money back" response is both immature and unprofessional. It's the equivalent of "if you don't like it, I'll take my ball and go home." Users have already invested in the "game". Giving our money back isn't going to make us whole. Just acknowledge the problem and provide us with your insight and assessment. Then we can make intelligent decisions about how and if to use the product. Throughout all the indignant complaining about Timur's input, there still is no problem assessment and feedback from Ableton support on the issues. I have no way to judge whether I should move back to XP and invest the considerable time it will take to do so. If I do it, will Ableton have a fix the day after I've invested the time? At present, I have no way of making that judgment.
and the "if you don't like our support, we'll give you your money back" response is both immature and unprofessional. It's the equivalent of "if you don't like it, I'll take my ball and go home." Users have already invested in the "game". Giving our money back isn't going to make us whole. Just acknowledge the problem and provide us with your insight and assessment. Then we can make intelligent decisions about how and if to use the product. Throughout all the indignant complaining about Timur's input, there still is no problem assessment and feedback from Ableton support on the issues. I have no way to judge whether I should move back to XP and invest the considerable time it will take to do so. If I do it, will Ableton have a fix the day after I've invested the time? At present, I have no way of making that judgment.
dom wrote:Besides all the technical stuff: I hope you enjoyed a few great days in the sun last week and hope you're filled with inspiration!
How does that come between you and your inspiration in any way, if you have a working XP setup for making music, like you say you do? Seriously: when you're feeling inspired, it's only logical to boot up your working DAW environment, lose yourself into making music, and forget about the technical troubles you're having on another OS.Timur wrote:Yes, quite inspirational, until I came back home and had to deal with Live's issues again and which. As I am writing this Live runs idle at 50% in the background doing nothing but heating up my room.
It's remarkable that you're willing to pour so much of your personal time into battling with technical troubles, documenting the issues to benefit other users. It really shows persistence and attention to detail. But talk like that (a vibe of inspiration lost after coming home and, for some reason, trying to use the non-functional system instead of the functional one) just sounds weird. When you really have an inspiration to make music, and you already know what works and what doesn't, realize your inspiration using the thing that works.
What I meant is that it's drawing my attention away from the inspiration. Here I am half a week away from Barcelona and my head is filled with all the technical issues stuff instead of thinking back to what I experienced there. My "working" XP setup is due for a fresh reinstall as is my whole PC. I'm waiting to buy new hardware and do a clean install of Windows Vista on that just as soon as Ableton Live becomes Vista compatible.Nokatus wrote:How does that come between you and your inspiration in any way, if you have a working XP setup for making music, like you say you do?
Another reason why I put so much effort into trying to help Ableton to get their act together is because I can. You will hardly find any other user out there who comes with so much experience and insight into how Windows PC systems work and my personal experience with Support shows that sometimes I'm better and finding problems and possible workarounds than Ableton themselves. I wish it was different and I really tried to just send them short mails that only describe the issue and then hoping/waiting for them to help me. It took two months and didn't work out at all, not because they didn't try, but seemingly because they weren't able to(n). So after waiting such a long time for no solution coming up I decided to go back into my old scheme of investigating things myself. At least I have some workaround solutions now and could even convice RME that part of my problems was in fact not a fault of Live. That could have happened two months earlier if I had not relied on Ableton support in the first place. Sad but true...
Currently I am working with RME to fix their Vista drivers and it's been a more satisfying experience so far. Not only do they provide beta-driver fixes quickly, but they also ask knowledgeable questions and discuss reports in order to understand the problem at hand (which enables them to offer such quick solutions). But even with RME I had to provide all the informations I posted in this thread in order to help them adress the issues.
Lots of Quality Assurance and Beta Testing is done by end-users today, hopefully that wont happen as extreme with cars and airplanes once. You don't want those to see those crash while you're using them, do you?
But to stay fair, those things are far more expensive than most software, so it's also a thing of relations.Anyway, tonight I'll meet with my collaboration partner to prepare for an album and future gigs. He's using Live on a MAC anyway.MC wrote:To simplify further testing the new Windows driver 2.895 for the Firefaces includes a checkbox to disable its MMCSS support (Settings, About).
http://www.rme-audio.de/download/w2fire_2895.zip
This does not change the applications MMCSS support, so it will be interesting which effect switching off one or both (via services) has.
Regards
Matthias Carstens
RME
So here come the results for 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 get's 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.
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 get's 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.
Last edited by Timur on Thu Jul 03, 2008 9:49 am, edited 1 time in total.
timur, you´re a bullethead and a victim of our time! i realy don´t understand why you don´t use a running and tested system (xp), especially if your upgrading to a new computer (you should know how fast an old xp system runs on new brand new machines). your explanations are nice, but you´re not the only one knowing detailed inside win stuff. i disbelieve that you will hardly find users with excellent win system knowledge, there are many guys out there knowing a lot of stuff you never dreamed of. maybe such guys don´t have a need for an exaggerated showmanship. as you already mentioned you´re not a coder. this means that you´re only scratching on the win surface when you talk about threads and prioirities. and avery child knows that microsoft keeps many things of their system secret. outsiders of microshit, and that of course includes mll 3rd party developers, must rely on tnformation ms provides.
btw you said that maybe rme did something wrong in choosing the right task (audio / pro audio) in their code. i can´t imgagine that their developers aren´t able to read the http://msdn.microsoft.com/en-us/library ... S.85).aspx
i realy don´t understand why you don´t use a running and tested system (xp), especially if your upgrading to a new computer (you should know how fast an old xp system runs on new brand new machines). your explanations are nice, but you´re not the only one knowing detailed inside win stuff. i disbelieve that you will hardly find users with excellent win system knowledge, there are many guys out there knowing a lot of stuff you never dreamed of. maybe such guys don´t have a need for an exaggerated showmanship. as you already mentioned you´re not a coder. this means that you´re only scratching on the win surface when you talk about threads and prioirities. and avery child knows that microsoft keeps many things of their system secret. outsiders of microshit, and that of course includes mll 3rd party developers, must rely on tnformation ms provides. btw you said that maybe rme did something wrong in choosing the right task (audio / pro audio) in their code. i can´t imgagine that their developers aren´t able to read the http://msdn.microsoft.com/en-us/library ... S.85).aspx