Optimizing CPU peformance on Ryzen 5000 series (10+ cores)

[planet_b]

Greetings fellow musicians!

I'm a Live user since version 5. Over all these years, I've gotten very used to the workflow and to the way things are done in Live. I understand that the focus of the development is to make it the ultimate live performance tool, and for that it is perfect. But one thing that's never been it's strength, is CPU efficiency.

So I'm asking for little help trying to optimize my workflow, to get more juice out of my desktop setup:

Live 11.2 on AMD Ryzen 5950x (16 core, 32 thread), Asus ROG Strix X570-E Gaming, 32GB DDR4 @3200MHz, RTX 3060, M-Audio M-Track 2x2 USB-C audio interface (ASIO buffer size 4096), Windows 10, all drivers (AMD chipset etc) drivers up to date

SMT (AMD's version of "hyperthreading") is ON, so 32 threads in use. When I built this setup, I tested both with off and on, SMT on gave more fluid overall performance. I cannot switch it on and off any more to test, as half of my installed plugins will deauthorize themselves due to number of CPU cores changing (thinking it's not the same PC). And it would be a complete pain to see which ones did and which did not..

Windows power profile is on "ultimate performance" and with Power Option Explorer software I have un-hidden dozens of CPU options which are not visible in the default setup. So trust me, I have tried to figure this out..
Also worth noting, that Ryzen 5000 series don't care about the ordinary "minimum/maximum processor state", it doesn't do anything. This is why AMD optimized power profiles are not even installed when you have 5000 series CPU, as they make very little difference.

So, this is the CPU overload issue, as you can see on this image: https://i.imgur.com/W2OzdNV.jpg

There you can also see the kind of plugins that I'm typically running, nothing too crazy. Softsynths, with some basic Kontakt pianos. It's all MIDI tracks, not a single audio track there.
Most of the CPU cores are not sleeping, but running in very low clock ratio's. Core #01 is with the highest load but not at the max clock rate it could run (about 4.6GHz sustained).
But yet, Live CPU overload light is on very early and the audio starts to break.

I am not seeking for low latency, that's why I have my ASIO buffer set at 4096 for testing. I've tried ASIO4ALL too, but the overloads will begin earlier.

I have read a ton of forum posts when it comes to getting most out of your setup, it's been pointed out that when you start routing audio of your plugin's output to other channels (instead of master bus), then those will become one long processing chain. So I tried this out on my setup.

If I make a blank project, start placing Diva's with basic arpeggiator on repeat, with the multicore setting on.. I can reach to about 150 channels until the audio starts to break and Live's CPU overload light is on.
Then, I try setting up audio tracks with monitoring ON, and route 8 Diva's audio output to each. So now I have 20 audio tracks, with each 8 Diva's audio routed to it. It doesn't make any difference, still reaching about 150 tracks.
While this 150 tracks may sound completely bonkers and unnecessary amount, in reality - when you start making real work.. it is nowhere even close to this! The audio starts breaking up in very early stages if you look at Window's own task manager.

At some point Live got this new feature "CPU overload meter" under the track mixers. This doesn't help at all. It might display zero indicators on most tracks, and then some identical track have 3 indicators on. It seems a bit random and it doesn't reflect anything in reality. The CPU is nowhere near overheating at 60-70°C (42-44°C is the typical idle temperature for 5950x, and on load it's designed to sustain even 85°C)

So now my question is.. anyone with similar AMD setups, how have you configured your CPU in BIOS, overclock etc, Windows power options etc.? Your audio routing from tracks, etc?

Thankful for any advice..

[[nil]]

Hi,

I would be curious if you could try setting in your Options.txt the MaxAudioThreads variable, to limit the number of concurrent audio threads, for instance:

Code: Select all

-MaxAudioThreads=32

On your machine with SMT at the moment Live will by default allocate a large amount of threads, around 64, which might be counterproductive. In any case this will provide an easier way for you to control concurrency without having to toggle SMT on/off in your bios.

At some point Live got this new feature "CPU overload meter" under the track mixers. This doesn't help at all. It might display zero indicators on most tracks, and then some identical track have 3 indicators on. It seems a bit random and it doesn't reflect anything in reality. The CPU is nowhere near overheating at 60-70°C (42-44°C is the typical idle temperature for 5950x, and on load it's designed to sustain even 85°C)

The performance meters below each track will light up on the tracks that are on the "critical path" for Live's audio engine to meet the audio driver's deadline. In your case when you say it's a bit at random, are the same tracks always lit up or are the performance meters lighting up on different tracks each time?

If you have the time, we could take a performance trace on your machine using Microsoft's performance tracing tools, so as to see what's going on "under the hood"

Here are some instructions:

• First, download and install the latest release of UIForETW at https://github.com/google/UIforETW/releases: Download etwpackage1.58.zip, extract all to a folder it, then
• Inside that folder go inside etwpackage then bin then run UIforETW.exe. It will quickly install a small package from microsoft called WPT (Windows Performance Toolkit) then show its main window.
• Inside the "UI For ETW" window, press the "Start Tracing" button at the top-left corner.
• Then start Ableton Live, open the Set that causes you trouble, interact with it a bit until you encounter the performance issue.
• Alt-Tab to the UIForETW window and press the "Save Trace Buffers" button at the top-left corner.
• After some time, the UI for ETW window will show a new element in the "Traces" list on the left. You can click on it, press F2 to give it a name or even add some documentation about what you were doing in the "Trace information" section to the right.
• Then right-click the trace, click "browse folder" in the context menu and you should find a .etl file and possibly a .txt file next to it.
• Compress that .etl file (and any .txt file next to it) to a zip file (right click on the .etl file in Windows Explorer and choose "Compress to Zip file")
• Send the link to me privately. As the file can be quite large, we have to use something like Google Drive, Dropbox or Wetransfer

If our instructions are somewhat not clear, here's how Google explains the same thing: https://support.google.com/chrome/a/ans ... e-etw-data

[B4L]

You do need to control the cpu power states - min and max should be set to 100% and the cooling policy should be set to active. If that doesn't work from inside Windows, you might be able to control it in the bios.

Something else you should check is to make sure the usb ports are not going to sleep to save power - they should be configured to always stay on

Re drivers, I wouldn't recommend asio4all - keep using the maudio ones.

But you should try disabling SMT to see what effect that has as well

[planet_b]

You do need to control the cpu power states - min and max should be set to 100% and the cooling policy should be set to active. If that doesn't work from inside Windows, you might be able to control it in the bios.

Something else you should check is to make sure the usb ports are not going to sleep to save power - they should be configured to always stay on

Re drivers, I wouldn't recommend asio4all - keep using the maudio ones.

But you should try disabling SMT to see what effect that has as well

I've sent the ETW trace as requested by [nil]. We'll see what further tests we'll need to go into.

Regarding the CPU power control, life with Intel i8700k was very simple - for regular desktop use, just set power saver which let the CPU sleep when on low loads, and max power (which sets those min/max power states to 100 as you mentioned) when doing DAW work.

But on Ryzen 5000, those are ignored. Power Settings Explorer let's you unhide dozens of power options that are not visible by default. There are some that have very dramatic effect on how it reacts.

USB power saver has been disabled also, as it was causing audio stutter even on some standard video playback (this is Ryzen 5000 related issue, but luckily this fixes it).

I'll resort to disabling SMT if Ableton supports asks to do so. As it WILL break authorizations on loads of plugins which think it's no longer the same PC. Massive hassle will follow..

[[nil]]

Before disabling SMT, try playing with the Options.txt's -MaxAudioThreads=32 and see if lowering it to 16, 8 helps out.

What I see at first glance in the .etl trace is that Live's engine is trying to parallelize as much as possible but the cost of coordinating so many threads appears quite large. This would explain why the task manager says you're not using the CPU much but we still get dropouts, as threads are waiting for each other and spending time coordinating.

[planet_b]

Before disabling SMT, try playing with the Options.txt's -MaxAudioThreads=32 and see if lowering it to 16, 8 helps out.

Tested, 32 gives the best performance (it was the setting during the trace).
16 will increase the Live meter's reading from 55-60% to 70-80% prior to enabling the heavy plugins, after which it'll shoot to 115-120% overload
8 will further add Live meter's load and it seem to cause even a laggy Live

This is why I originally ended up with leaving SMT on, as the overall fluidness of everything under load was better.

But, if for testing purposes I need to turn it off - I shall do so. I just need to mentally prepare for hunting all those plugins which have de-authorized and are randomly transmitting hissing or whatever random punishment the dev's have figured suits them best.

[[nil]]

Thanks for trying the MaxAudioThreads settings!

I wouldn't try without SMT at this point, it seems more trouble than its worth.

[planet_b]

Thanks for trying the MaxAudioThreads settings!

I wouldn't try without SMT at this point, it seems more trouble than its worth.

Allrighty then, it's a relief.. Live also craps out it's authorization at the point of switching SMT.

What you said about the initial findings with the trace, about the large number of threads waiting and coordinating - is this something that could be changed in future versions? I could test out experimental alpha versions with my setup..

[[nil]]

Thanks for the collaboration offer!

About the trace: From the trace only I cannot yet know whether / how much the coordination work is useful or wasteful. This depends on your set and how tracks and audio flow into one another. So ideally we would need to have the set as well to inspect the signal path.

I have colleagues working on these topics, I'm forwarding info from you / this thread.