All Live/Vista performance problems identified!

[Timur]

Hey folks!

I thought that I should let you know that after two more days of diving into my Vista/Live/RME related problems I am now able to identify and reproduce about all of them.

Additionally I think to have found the source/reason for the bad performance of RME Fireface drivers on Vista and I am able to reproduce their performance hit in Reaper now. So this is not a sole problem of Live, but it's alot worse in Live than in Reaper.

(Furthermore I found some very interesting performance problems with Live 6/7's multiprocessing methods on both Vista and XP that should be discussed in detail. Likely this ain't no Live specific problem though, but a problem of multiprocessing overhead in general.)

And No, turning off multiprocessing does not solve any of these issues, it just alleviates the symptoms.

Some of these were reported as early as January by me (AERO anyone?) and Ableton was not able to solve or even successfuly reproducing them.

Meanwhile I have been told not to spend time on analysing things on my own, not to write thorough reports to support "No 300+ words mail!") and not to draw my own conclusions. But in the end I prefer drawing my own limited and amateurish conclusions to getting no conclusions at all.

If you are only interested in the solutions then skip the entire "Analysis" and "Proof" sections!

[Timur]

Ok, here comes the complete list of what I've found:

1. Problem: Unuseable performance when Aero is deactivated (Basic Desktop)

Symptoms: High CPU load, sound breaking up, sluggish response

Analysis: Live main thread - which is responsible for drawing the GUI - constantly bombards the graphic-card driver with calls when running on Vista without Aero which in turn produces high/maximum CPU load on one CPU core. This does not happen on XP and can be cured by putting Live to background and then chaning screen-resolution (can be switched back to original afterwards). But as soon as Live's windows is restored the problem occurs again. This happens on both AMD and INTEL plattforms with both NVidia and ATI cards on different chipsets.

Proof:

This is what Live is doing on Vista Basic Desktop



This is what Live should be doing instead



Current status: Ableton knows about this problem since January (!!!), but didn't show any motivation to reproduce, analyse or solve it.

Solution: Turning on Aero is a somewhat useable workaround, because then Windows' Desktop Windows Manager (DWM.EXE) is responsible for drawing the GUI. But this workaround may come with yet another considerable performance drawback (see 2. Problem below). The only real solution would be for Ableton to take a close look at their GUI drawing scheme and find out why it bombards the graphic-card driver with calls that do not happen on XP/Aero/background after resolution switching.

Conclusion: Live is not fully Vista compatible!

[Timur]

2. Problem: Bad performance with low audio-buffers or high CPU-load when activating Aero (3D desktop)

Symptoms: Generally worse performance compared to Windows XP like audio crackling, especially when desktop specific actions are happening (like restoring a window from the task-bar).

Analysis: When Aero is turned on then the Desktop Windows Manager (DWM.EXE) becomes responsible for drawing all GUI elements of both the desktop and all applications. It's threads run at highest priority 15, just like Live's audio-related threads. Even worse, Live's main/GUI thread runs at priority 8-10 only. So any action of DWM will either supersede or at least equal Live's own threads.

Proof:




Current status: Like with problem no. 1, Ableton knows about this since January (!!!), but has shown no interest into investigating possible solutions.

Solutions: Manually switching Live's priority to "Realtime" will make its main/GUI thread run at priority 24 and its audio-threads run at priority 31. This will solve any Aero and other priority related problems because Live's threads will supersede all of them. Unfortunately there are considerable drawbacks in that your PC becomes kind of a Live-Only machine. If you ever happen to max out your CPU load by turning on one effect too much your PC will become completely unresponsive since Live's audio-threads supersede all others. You can neither use Task-Manager (priority 15) nor Live's own GUI (priority 24) to stop Live from playing at once. You can only try to press stop (Live's GUI 24 thread) and hope that it ever happens before you give up and hit reset.

Like with problem no. 1 only Ableton can come up with a proper solution in that they either fix problem no. 1 or change the threading/priority scheme of Live by incorporating Vista's "Multimedia Class Scheduler Service" which allows applications to boost the priority of their multimedia related threads in a more "multitasking" manner than simply turning Live to Realtime priority.

Conclusion:Live is not fully Vista compatible![/b]

[Timur]

3. Problem:Unuseable performance when using RME (Fireface) drivers in combination with Live and Vista

Symptoms: Bad crackling even with only one audio-clip being played downto complete break-ups of the audio-driver that require to turn Live's audio-engine off and on again.

Analysis: This seems to be more of a problem with the RME-driver than Live, albeit it runs alot better when using Reaper with the very same RME-driver while other audio-interfaces/drivers run smooth with the very same Live/Vista combination. Problem here is that the RME-driver keeps changing its own Dynamic Priority in between 24 and downto priority 2 (or maybe even 1). Since even "Idle" processes use a higher priority of 4 the driver is often superseded by other threads/processes. Other audio-drivers and Live's own audio-threads (when turning on multiprocessing) use a priority of 15. Even when Live's priority is manually changed to Realtime (which forces all audio-threads including the audio-driver to priority 31) the RME-driver keeps changing its priorities. That should not happen at all, since all priorities between 16 and 31 are fixed and thus spared from dynamic changes by Windows.

Proof:

RME Fireface driver priorities with Live running at "Realtime" priority


Audio Recording of RME driver, Reaper, 20 looping tracks/samples, 88.2 kHz, 64 samples buffer, heavy system load by Windows Explorer ("Normal" priority):[/b]: http://www.zshare.net/audio/13614998cefb5337/

M-Audio Audiophile driver priorities with Live running at "Realtime" priority using the very same setup and CPU load as with the RME driver


Audio sample of M-Audio driver, Reaper, 20 looping tracks/samples, 88.2 kHz, 64 samples buffer, heavy system load by Windows Explorer ("Normal" priority): http://www.zshare.net/audio/136150716702a570/

Current status: Both RME and Ableton know about these problems since about 7 weeks. Both have pointed fingers at each other and at the Nforce4 chipset. After all this time Ableton was finally able to reproduce the problem and even found the source to be around the priorities of the RME driver. It took me about 2 hours to identify that once I got sick of waiting and did my own analysis right before Ableton's "We found something!" mail reached me. This shows that upto this point both companies either were not willing or nor able to reproduce and identify a problem which easily can be reproduced on several different system within minutes.

Ableton still claims that turning off Multiprocessor support cures the problem, but stated that they will try to find a solution with either the next or a later update (atm they fear that their solution could break other fundamental things). RME has finally taking actions and posted a first driver update on their forums. That driver update only pushes Base Priorities to "Realtime" though without fixing the ongoing switching of Dynamic Priorities.

All in all I am in good hope that the combined effort of Ableton and RME will finally lead to a real solution soon.

Solution: Turning off Multiprocessor support can help alleviate the symptoms by freeing up one core for system-processes, but will not cure the illness. Until a real solution is provided by Ableton/RME the there are two workaround solutions, with solution a) being preferable. RME also provides a beta driver via the following forum thread that tries to fix the problems: http://www.rme-audio.de/forum/viewtopic.php?id=3131

a) Turn off the MMCSS service via Windows' service list. This will force the RME driver to use a static priority of 15 again with no dynamic priority switching happening anymore.

You will get a warning that Windows Audio is depending on that service. If you need Windows Audio (for system sounds and the like) you can use the following Registry hack:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Audiosrv\DependOnService

Just remove MMCS from that key in the list, and set MMCS to disabled in services, then reboot.

b) Turn off Multiprocessor support in Live (this will also lower CPU overhead for audio-clips considerably) and manually force Live to use only one CPU core via Task-Manager (Affinity) while other processes are forced to use the other (especially Explorer.exe and DWM.exe).

Conclusion: We've come a long long way together, through the hard time and the good, I've got to celebrate you baby, I've gotta praise you like I should...

[Poster]

Current status: but didn't show any motivation to reproduce, analyse or solve it.

mate your persistence is, erm, admirable? but I really have no idea how you can claim this?

how do you know they're not on the case?
the fact that they don't get into a detailed discussion with you or others on this forum doesn't mean anything..

[duluxdog]

I really appreciate your efforts. I'm running a brand new laptop with 2core 2ghz processors, 2 gig RAM in XP service pack 3 and i'm having extensive crackling issues. I soon discovered disabling multi-processor support helps.. but the problem still occurs to some extent. The CPU monitor goes up like crazy when dual core support is enabled, along with this crackling audio. I'd love for this to be resolved as i'd like to be able to make proper use of the machine i've just splashed out on.

[Timur]

Current status: but didn't show any motivation to reproduce, analyse or solve it.

mate your persistence is, erm, admirable? but I really have no idea how you can claim this?

how do you know they're not on the case?
the fact that they don't get into a detailed discussion with you or others on this forum doesn't mean anything..

Well, I must admit that in January I got an email telling me: "We are already looking into this. I can't tell you any much yet though." I can also remember one answer being "We didn't change nothing about the GUI drawing in Live", which was a clear suggestion of "Vista is to be blamed". Later that theme changed to "NVidia is to be blamed" for this and other problems.

In april Amaury posted this on the forum:

All we all know is: "for some users who use Nvidia hardware and Vista, Aero gives better results."

If large experiments need to be done, we're happy to do them, in the time we can afford to do them, and we, ultimately, decide about that. We even decide if it should be done at all or not. And we never, ever, would rely on, or ask users to do so."

After that I did as he told me and kept waiting and waiting and waiting and waiting for Ableton's highly qualified engineers to solve my support requests. Fortunately I had alot of other things to do meanwhile and did not have to rely on things to work within the week.

So now it's June and I have not heard back from Ableton on the matter anymore, neither through mail nor through forum, which wakened my impatience. Now thinking about the fact that the "for some user who use NVidia hardware" statement was already 4 months later than the initial reports of the problem and that now 2 months later they still haven't solved the riddle makes me somewhat think that they lack interest <using the voice of the doctor in Enterprise NX-01 to underline sarcasm>. Considering even more that it took me only minutes (!!!) to reproduce the problems on different hardware that didn't have a single Nvidia part inside makes me even more suspicious about how much effort Ableton might have put into investigating the issues. This... kind of... ensured me... that the problem was given low priority.

[Timur]

I really appreciate your efforts. I'm running a brand new laptop with 2core 2ghz processors, 2 gig RAM in XP service pack 3 and i'm having extensive crackling issues. I soon discovered disabling multi-processor support helps.. but the problem still occurs to some extent. The CPU monitor goes up like crazy when dual core support is enabled, along with this crackling audio. I'd love for this to be resolved as i'd like to be able to make proper use of the machine i've just splashed out on.

Duluxdog, since your issues are Windows XP related please start a new thread, I might be able to help you there, but let's keep this thread about Vista only.

[[nis]]

Both have pointed fingers at each other and at the Nforce4 chipset.

This shows that upto this point both companies either were not willing or nor able to reproduce and identify a problem

Im wondering where you got such information from? We have never pointed any fingers on whatever company, nor are we not willing to investigate in any problems. What are you trying to achieve with your insulting and false comments?

[Timur]

Im wondering where you got such information from? We have never pointed any fingers on whatever company, nor are we not willing to investigate in any problems. What are you trying to achieve with your insulting and false comments?

The only thing I'm trying to achieve is for Ableton to get their act together and solve its bugs and problems in a timely manner. I'm not insulting anyone here, else I would be using much stronger words to describe how I feel about the quality of your support. This here is only a Vista related thread, I will start several others about my other issues again soon, which also have not been handled by Ableton for several months now (meaning they still have not even been reproduced and acknowledged as problems by you).

My comments are not false, I'm just reading between the lines of your and RME's comments and interprete inconcrete answers I got from you in return for reporting the issues.

I'm afraid I can't contribute much here - if Reaper (and other ASIO software) does not show any such problems, there does not seem to be a general FF problem. Is the FF connected to onboard FW?

So, "there does not seem to be a general FF problem" then it must be a problem of either my setup/system or Ableton Live, the answer does not allow any other interpretation. RME simply ignored that I reported about my other two audio-interfaces not leading to crippled audio-output and did not contribute any further assistance from that point until we proved that their driver's priorities are running havoc. Furthermore I was not offered any help in which part of my system could cause the problems if Ableton was not the culprit. On the other hand they are very supportive now and trying to provide quick and concrete help in order to get the issues solved as fast as possible!

Hmmm...wir hatten neulich einen ähnlichen Fall (übrigens auch NForce4), bei dem das FF400 nur unter deaktiviertem Multiprozessor Support funktioniert hat.

"Hmmm...we had a similiar case lately (also NForce4 btw) where the FF400 functioned only when deactivating Multiprocessor Support."

Liegt das am Rechner (NForce4) oder an Live?

"Is the PC to be blamed (NForce4) or Live?"

Schwer zu sagen. Laut deiner Problembeschreibung hört es sich so an, als wären mehrere Komponenten daran beteiligt. Der NForce4 Chipsatz ist schwer umstritten. Angeblich werden wohl die PCI-e Slots bevorzugt behandelt, was zu starken Performance-Einbrüchen an den normalen PCI Slots und auch anderen Komponenten führen kann (vor allem auch am Firewire Controller). RME selbst hat dazu mal einen umfangreichen Artikel veröffentlicht (bezieht sich allerdings auf das ältere Single-Core Modell):
http://www.rme-audio.de/english/techinf ... _tests.htm

Um Probleme mit Firewire Interfaces in den Griff zu bekommen, wird meist empfohlen, einen PCI-e Firewire-Controller zu verwenden.

Warum das ganze nun unter XP funktioniert, aber nicht unter Vista und warum Reaper keine Probleme macht, ist mir selbst unerklärlich. Wir machen ja im Grunde nichts anders als Reaper, wenn wir alle Audio Daten an den RME Treiber übergeben. Es kann also nur sein, dass eine 3.
Komponente, die im Zusammenhang mit Live steht, das Fass zum Überlaufen bringt. Leider haben wir keinen Rechner mit einem NForce4 Chipsatz hier, d.h. das Ganze ist für uns etwas schwierig zu testen.

Ich werde auch noch mal RME dazu kontaktieren, vielleicht haben die ein paar genauere Informationen.

"Hard to say. According to your description of the problem it sounds like several components are involved."

Comment: In reality several Live issues were involved, all listed here.

"The NForce4 chipset is heavily disputed. Reportedly the PCI-E slots are handled priviledged, which can lead to strong performance-drops on the normal PCI slots and other components (especially on the Firewire controller). RME themselves have published a detailed article about that once (which references to the older single-core model though):
<link>

To solve problems with Firewire Interfaces it's usually recommended to use a PCI-e Firewire Controller.

Comment: As far as I am aware the only "native" PCI-e controllers out there are using an Agere/LSI chipset that is heavily disputed to cause bus-resets with audio-interfaces (RME reported that about the Macbook Pro in their forum and did their own tests with Windows and other audio-interfaces as well). They are strongly suggesting not to use such a PCI-e controller.

"Why the whole thing functions on XP but not on Vista and why Reaper shows no problems is unexplainable to me. Basically we do nothing different than Reaper when we deliver audio data to the RME driver. The only possibility is for a third (3.) component which is connected to Live to be the last straw (to break the camels back). Unfortunately we don't have no system with a NForce4 chipset here, which means that the whole thing is hard to test for us.

I will contact RME on that, maybe they have more detailed informations."

Comment: For me the whole statement boils down to generally blaming the NForce4 chipset and pointing to RME to deliver further informations about the possible source of the problems. It doesn't make me wonder that it took you 7 weeks to identify thread-priorisation in combination with the RME driver as source of the problem, you were looking into the wrong direction most of the time. That's ok, nobody's perfect, but you can hardly expect me to be happy about wasting my time with wrong support results and praise you for finally put away the blinders and do a proper and indeep analysis of the problem.

[Timur]

Hi Timur,

thanks for testing. Sorry if you feel abused as beta tester, but in this case (as from thousands of users having no problem) I really think you are helping mainly yourself by investing some time here.

When we started with the Vista drivers we added the MMCSS stuff and looked for the priorities, which are handled differrently to XP. We found that there is nearly no performance difference changing them, and that the DAW software itself should take care of everything. We also noticed that elevating the driver will cause the app to follow, which caused some incompatibilities. So we removed this stuff again.

Because of your post here we added the old stuff again (that's why we could react so quick). Nevertheless we can't believe that any priority setting on our side will solve your problem. The audio file clearly shows that you have a BIG problem in your system. Changing our priority is more like fine-tuning, so it might get better (and I am thankful for the opportunity to check this, as on a normal system you would see no difference), but it will never be perfect. The M-Audio is PCI, right?

Anyway, your feedback made us rework the old routines again. The new driver 2.894 now shows a static p. of 15, and a fixed dynamic p. of 26. The app is no longer elevated to realtime. Note that there is a second thread with different p. - that is the TCO, and no problem whatever it shows.

I would appreciate much if you install that driver and try again how severe your audio problems are. And maybe you can even proof us to be wrong...

http://www.rme-audio.de/download/w2fire_2894.zip
Regards
Matthias Carstens
RME

Obviously RME didn't feel any much "insulted" but apologizes for the inconviniences and proceeds to finding solutions for the issues. Beside the long waiting time for this specific issue I am very happy with their support, also because they have provided very quick feedback/help with other questions in the past instead of piling up more and more untreated problems on the list. Furthermore they always show a good degree of insight and knowledge about all technical aspects and system-internals and obviously know what they are talking about.

[[nis]]

You are getting some things mixed up here. But I'm not going to discuss that with you, as you will always have the last word anyway. On a side note, our support email signatures were made to read them.

As you surely might have noticed, we were finally able to find the cause of the RME problem and as I wrote you, we're now testing an internal version to check how it behaves with all other interfaces. Btw, I actually brought my very own Fireface 400 to check your stuff as quickly as possible, which left my studio out of order for quite some time now. However, RME, whose support is indeed very good since day one, has released a new driver version for you. What else do you want? 24/7 private support and magical solutions out of a hat?

[hoffman2k]

Dips on the hat! I want the Live box in the shape of a unicorn!

[Timur]

On a side note, our support email signatures were made to read them.

On a side note, my bug-reports were made to read them. But you are right, I did not remember that part of your signature because I was too focused on countering your accusations.

Ableton does not authorize any publication of the content of this e-mail without the permission of the author.

Fortunately I do have a private legal protection insurrance, just in case you want to sue me now.

As you surely might have noticed, we were finally able to find the cause of the RME problem and as I wrote you, we're now testing an internal version to check how it behaves with all other interfaces.

Since it took you so long to write back I noticed only after doing my own research, and I am very glad I did, because in your "solution" mail you are still insisting that turning off multiprocessing makes Live run "flawless". Seemingly your results are less complete than mine even after so many weeks.

What else do you want? 24/7 private support and magical solutions out of a hat?

You need to understand that this paying customer is less embarassed by only the specific RME related problems, but by the fact that this is just the latest of a long row of issues that I am waiting to get proper support for. Heck, 2 months for finally acknowledging an issue and promising a solution is like a revelation when being compared to 6 months of not getting any useful response for all the other problems I reported in detail (beside the demand by Amaury to stop buggering Ableton support with detailed reports).

Now let's stop the bickering, get your act together and analyze the reproduceable problems I've been reporting since months. While you are busy accusing me to insult your feelings RME and I are busy solving the problem. Their latest driver, which I am testing right now, comes one step closer to that, but doesn't cure the cause yet.

[Timur]

RME and Ableton are working on problem no. 3 now, great!

Problem no. 2 would be solveable by using MMCSS for priorisation over DWM/Aero, which I don't expect to happen too soon from Ableton's side, but I know that RME already tested this via its drivers. Still the DAW would be the better part to have control over priorities than the driver. By incorporating this Ableton Live would become Vista Aero compatible without need to manually change it priority to Realtime.

My most urgend question now is: Will problem no. 1 be analyzed and solved anytime soon? Will Ableton Live become Vista Basic Mode compatible after so many months of waiting?