PreSonus Forums

Hi dear family. I posted this on Facebook but thought it was a better idea to post it here.

I would like to talk about the famous "CPU optimization issues in Studio One" that lots of users talk about. I did some investigations and would like to submit my "findings" to the dev team in order to acknowledge (or refute, or at least explain) what I witness and see if it can help for further improvements regarding multi-core CPU usage in S1.

It's quite long so I did it in several parts. S1 users bear with me, it's a bit geeky but very interesting in my opinion.

PART 1 – The CPU optimization issue

That subject bothers me a lot. I mean a lot. I have a crazy silly CPU configuration (a dual E5-2680v2, overclocked @3.44 GHz, with a total of 20 cores/40 threads), but still when mixing on Studio One I pretty much run into a bottleneck rapidly as soon as I have an "above usual" count of plugins.

What do I mean? I mean the CPU maxes out on the Performance Bar in S1 and I start to have dropouts. I cannot stand having dropouts, actually nobody does. But here's the thing: when I open the Windows' Performance Monitor (I'm on Windows 10 x64) I can see that *globally* my CPU is absolutely not maxed out, it's about at 20-30% usage. What?

So what's wrong? Many of you now know that Studio One's CPU gauge doesn't show your *global* CPU usage, but the usage of the *CORE* that utilizes the most CPU (which makes the CPU gauges in different DAWs absolutely not comparable, but that's not my point here). Now that means that actually I have one (or several) cores that are maxed out; and it happens that indeed Windows' Performance Monitor is showing a 20-30% global CPU usage but with one core at 100% or so. And for all the mixing projects that I encountered dropouts on, there always is ONE CORE that is at 100%. And the other cores are very low in usage, like between a couple % to 50%. Come on? There's all this crazy amount of free CPU to play with, and just ONE CORE is messing things up?

That raises a few (respectful) questions:

• 1 core at 100% + all the others at 20-30% on average: how can Studio One not use these other cores judiciously?
• Why having multicore CPUs if Studio One cannot take advantage of them?
• And also the one that intrigues me the most: how does it happen that each time I'm experiencing a maxed out CPU gauge and dropouts, there's always *one* and only one single core that is maxed out?

I wanted to investigate in order to have an answer. At least a beginning of answer, that I wanted to share with you and maybe discuss with the Studio One staff in order to get some improvements regarding multicore CPU handling.

PART 2 – My hypothesis

The first clue I had during my understanding quest, is that I was sure that it had to do with the way Studio One handles BUSES. Do the test: if you're running the same situation as me (you have a S1 CPU gauge at 100% and dropouts, and your Perf. Monitor shows that only one core is at 100%): select all your tracks/Buses/FX Channels and route them directly to the Master (basically you are bypassing the "bus function" in Studio One, making things all "flat") => normally you will witness a MASSIVE drop in the CPU gauge, while having exactly the same amount of plugins switched on.

It seems indeed to have to do with buses. And my computer programming background helped me quite a bit here. My understanding of buses made me kind of have a vision of how things could be implemented under the hood. When you have several tracks, that have some FX plugins on them, and that are routed to a bus that also has FX plugins on it, the bus has to wait for the processing on ALL the tracks to be finished before doing its own processing. Basic stuff right? So it has to do with synchronization. For each Bus and FX Channel you have to have a conductor/a manager that makes sure to synchronize the processing of their “children”; and if you have buses routed to buses, there must be some kind of “super-conductor” that must synchronize theses conductors, and the more Buses and Sends you have, the more complex the synchronization becomes.

My hypothesis is this one: all of this synchronization/or at least most of this synchronization happens *in one single Thread*, particularly the “super-conductor” of all conductors – The Master Bus – which is the last synchronization happening before routing the Audio stream to Audio driver, and which is the most complex. This would explain why I witness each time a single core at 100% and, consequently, dropouts. And it would also explain why there is a massive drop in CPU usage on that core when I route every track/Bus/FX Channel directly to the Master, i.e. when basically I bypass all the bus synchronization process (except the Master Bus of course, which has not so much work to do when doing so).

PART 3 – Some facts

Now look at that pictures attached to this post. They are from Process Explorer, a free tool by Sysinternals that I launched before launching Studio One and opening a “problematic” mixing session (note : I did it with a couple sessions and I always get the same results).

• On the first picture you can see that the most CPU demanding Thread in Studio One (running my problematic song) is the one related to the Audio driver (RDAS1117.DLL is the driver of my audio card). Its amount of CPU is huge! From my understanding this is the thread streaming audio to the driver, maybe it’s the parent synchronization thread – the “super conductor” I was talking about earlier. This thread is doing A LOT.
  Look at the red circle at the bottom, it says “Ideal Processor: 2” > this corresponds to what I see in the Perf. Monitor: it is indeed my Core #2 that is maxed out, reaching 100% CPU utilization, and this thread is responsible for that.
  
  Now we want to know: what is this thread doing? Well, Process Explorer gives us some clues.
  
  
• Look at the second picture (that I sliced in order to accommodate the overly restricted image size rules in the forum, but anyways): it is the detailed call stack of that thread. You can see that there is some synchronization going on, and that some processing is going on (Virtual Tape Machines from Slate Digital in this case). See that? Now when I click the Refresh button, the stack stays the same but this time another FX plugin is being processed. I clicked Refresh dozens of times and each time a different plugin is being processed *** AND THE MAIN THING IS THIS ONE: those are not only the plugins that I have on my Master Bus, those are plugins that I have on tracks, buses, sub-buses and FX channels! That one single thread is really doing A LOT.

PART 4 – Let’s discuss

Now I do not want to second guess what is exactly happening under the hood; I did some synchronization stuff in the past but not enough in the Windows environment to understand fully and interpret what I witness in Process Explorer. The thing I am pretty sure about, is that the “poor CPU optimization” in Studio One that lots of users mention and that I encounter often on big projects, is due to Bus and Synchronization management. There seems to be one Thread doing too much work, raising the utilization of the Core it is running on towards 100% while there are plenty other cores barely utilized. That is for sure a very undesirable bottleneck, that probably our beloved people in Hamburg could investigate on?

I am sure there is something to do about it. Maybe it would require redesigning some things, but in my opinion if the load could be spread more evenly amongst the CPU Cores, it would be worth the hassle and it would push Studio One to the very next level where our beloved DAW pretty much would be incriticable (uncriticizable?) on the CPU optimization subject. It would rule and give the example to the other DAWs (yes I know, Reaper seams to be performing well, but I don't know Reaper, I can't say much).

I know this is a tough subject. I just cannot imagine how complex the synchronization under the hood must be, with delay compensation, Mix FX and all that, it must be a nightmare, but could it be the dev team investigate into that?

I do think it is a subject our community does care a lot about -- and it is a subject that non Studio One users are also watching. The reputation and image of Studio One is greatly involved here.

What about you my fellow Studio One mates? What do you think about those "findings"? Has any of you investigated deeper into the subject and got interesting info to discuss?

Sorry for that long read. Sorry also for my bad English and my typos, although I tried to be as clear and clean as possible. Cheers! Let me know what you think.
Take care.

Soup' (my signature is up-to-date)

soupiraille wroteThe thing I am pretty sure about, is that the “poor CPU optimization” in Studio One that lots of users mention and that I encounter often on big projects, is due to Bus and Synchronization management.

Yet you say;

soupiraille wroteOn the first picture you can see that the most CPU demanding Thread in Studio One (running my problematic song) is the one related to the Audio driver (RDAS1117.DLL is the driver of my audio card). Its amount of CPU is huge!

Sorry, but I am missing something here. You have already identified your CPU bottleneck; it's your audio card and its hardware driver. Yet somehow this becomes “poor CPU optimization” in Studio One" and "due to Bus and Synchronization management" in your mind.

I'm confused by your assertion

Nice post soupiraille. I am still reading.

Many of you now know that Studio One's CPU gauge doesn't show your *global* CPU usage, but the usage of the *CORE* that utilizes the most CPU (which makes the CPU gauges in different DAWs absolutely not comparable, but that's not my point here).

You point is correct, however, your correction is also folklore.

Most people aside from the developer that wrote it would not understand the algorithm. I, for example, can create scenarios where I get 400-500% utilization and no pops or crackles.

Before I read further, I ask, are you hearing pops and crackles or just concerned about and commonly misunderstood meter?

Ok, read a little further into your actual questions.
What's hard for some to understand is multi-cores working on a task is not always the most efficient solution. Some tasks are too time critical to have context switching going on. Some tasks fit great for multi-core performance. It, not a situation where you always split everything evenly. So back to my original question.

Thanks

For Windows users some general performance tips...

1) If you have turbo features on your motherboard BIOS turn it off (such as hyperthreading). Also try turning off "high performance power".
2) In Windows power saving advanced you will see CPU min/max. Make sure these are on 100%
3) Update your display and audio drivers.
4) Consider updating motherboard BIOS
5) Make sure your antivirus excludes DAW processes and files (do not disable).
6) Goto Intel driver update website (or AMD equivalent).
7) Turn off windows non essential services
8) Turn off non essential startup processes.
9) Try to rule out the issue on a per project basis? Do you have a poorly behaved plugin for instance? (Do things return to normal if you remove a plugin?).
10) Turn off power saving features on your USB devices.

Then troubleshoot with process monitor and latencymon.
Also there are various optimizations you can do with a graphics card.
Always back up.

Turning off your network cards (such as WiFi) can also show a performance improvement.

And if all fails log a call with support:

Morticia wrote

soupiraille wroteThe thing I am pretty sure about, is that the “poor CPU optimization” in Studio One that lots of users mention and that I encounter often on big projects, is due to Bus and Synchronization management.

Yet you say;

soupiraille wroteOn the first picture you can see that the most CPU demanding Thread in Studio One (running my problematic song) is the one related to the Audio driver (RDAS1117.DLL is the driver of my audio card). Its amount of CPU is huge!

Sorry, but I am missing something here. You have already identified your CPU bottleneck; it's your audio card and its hardware driver. Yet somehow this becomes “poor CPU optimization” in Studio One" and "due to Bus and Synchronization management" in your mind.

I'm confused by your assertion

Hi. Actually if you look at the call stack you see that what's consuming CPU is not the driver but plugin processing, and there's a lot plugins being processed/running their code on this thread. I hope you're less confused!

jpettit wroteNice post soupiraille. I am still reading.

Many of you now know that Studio One's CPU gauge doesn't show your *global* CPU usage, but the usage of the *CORE* that utilizes the most CPU (which makes the CPU gauges in different DAWs absolutely not comparable, but that's not my point here).

You point is correct, however, your correction is also folklore.

Most people aside from the developer that wrote it would not understand the algorithm. I, for example, can create scenarios where I get 400-500% utilization and no pops or crackles.

Before I read further, I ask, are you hearing pops and crackles or just concerned about and commonly misunderstood meter?

Ok, read a little further into your actual questions.
What hard for some to understand is multi-cores working on a task is not always the most efficient solution. Some tasks are too time critical to have context switching going on. Some tasks fit great for multi-core performance. It, not a situation where you always split everything evenly. So back to my original question.

Thanks

Jpettit your point is 10000% valid: I'm not concerned with CPU reaching 100% but with dropouts. I do have dropouts, and it happens that these dropouts always occur when the CPU reaches 100%. (The reciprocal is not true: I don't always get dropouts when the CPU reaches 100% in S1, but most of the time I do).

100% agreed on the fact using multi cores is not always the way to go because of latency and synchronizing extra load.

I hope it answers your question. And thanks for being part of the discussion.

EDIT : yes my correction is folklore, the Studio One's CPU meter acts more like a dropout probability meter...

PreAl wroteFor Windows users some general performance tips...

1) If you have turbo features on your motherboard BIOS turn it off (such as hyperthreading). Also try turning off "high performance power".
2) In Windows power saving advanced you will see CPU min/max. Make sure these are on 100%
3) Update your display and audio drivers.
4) Consider updating motherboard BIOS
5) Make sure your antivirus excludes DAW processes and files (do not disable).
6) Goto Intel driver update website (or AMD equivalent).
7) Turn off windows non essential services
8) Turn off non essential startup processes.
9) Try to rule out the issue on a per project basis? Do you have a poorly behaved plugin for instance? (Do things return to normal if you remove a plugin?).
10) Turn off power saving features on your USB devices.

Then troubleshoot with process monitor and latencymon.
Also there are various optimizations you can do with a graphics card.
Always back up.

Turning off your network cards (such as WiFi) can also show a performance improvement.

And if all fails log a call with support:

Thanks a lot. I do ALL THAT you mention, every single point. And more

I wanted to submit this here, because I know it could potentially be brought to the attention of the dev team. Hopefully it will..

OK soupiraille

Still reading just a bit further as I am multi-tasking only my cores get tired this time of day.
Sorry if I missed this but on the hypothesis about Bus vs Channels vs Master (right track BTW) did you try a test with the same plugins? in other words Plugin in 1,2,3,4 on the buses (disabled/enabled) and plugin 1,2,3,4 in the main (disabled/enabled) to prove that hypothesis?

Also if you are really into looking at this at an OS level I suggest you create a test.song with all native plugins/instruments to demonstrate the behavior and that can be correlated across systems.

IMHO Make a video. Show us everything going on in your project before you start showing us process monitor and latencymon.etc.

PreAl wroteIMHO Make a video. Show us everything going on in your project before you start showing us process monitor and latencymon.etc.

There's nothing fancy. I just have songs, with tracks and buses, that maxes out the CPU and create dropouts, like lots of users encountered. There's nothing special in my way of doing things. A video of what I have won't be useful in my opinion.

jpettit wroteStill reading just a bit further as I am multi-tasking only my cores get tired this time of day.

lol

jpettit wroteSorry if I missed this but on the hypothesis about Bus vs Channels vs Master (right track BTW) did you try a test with the same plugins? in other words Plugin in 1,2,3,4 on the buses (disabled/enabled) and plugin 1,2,3,4 in the main (disabled/enabled) to prove that hypothesis?

I'm not quite sure to understand this test jpettit

jpettit wroteAlso if you are really into looking at this at an OS level I suggest you create a test.song with all native plugins/instruments to demonstrate the behavior and that can be correlated across systems.

I would and I pretty sure Morticia would be into that experiment as well as a few others.

At some point I'll have to do that if the devs ask I guess, yep. But actually you know, a S1 developer will understand right away the point when he/she will see the screenshots, because the behavior I am describing regarding that big thread is part of the S1's code. But sure if they ask I'll try to make a test project up (only Presonus plugins... I'm not sure it will work; or maybe yes, I'll see at that moment).

soupiraille wroteSorry if I missed this but on the hypothesis about Bus vs
At some point I'll have to do that if the devs ask I guess, yep. But actually you know, a S1 developer will understand right away the point when he/she will see the screenshots, because the behavior I am describing regarding that big thread is part of the S1's code.

You don't have any of the source code in front of you so it's unlikely you are going to know what code is triggering what or where it is. Anyway please post screenshots and videos I suggest. BTW you aren't the only developer here

And another thing:
https://answers.presonus.com/10836/mult ... nstruments

If it's not significant trouble, could someone give a list of what they consider the "non-essential services"? And for those of us who only connect to the internet for updates to software, can some of the networking services be put on either Manual, Manual (Trigered) [whatever difference that is], or Automatic (Delayed Start)?

Thanks,

Steve

PreAl wrote

soupiraille wroteSorry if I missed this but on the hypothesis about Bus vs
At some point I'll have to do that if the devs ask I guess, yep. But actually you know, a S1 developer will understand right away the point when he/she will see the screenshots, because the behavior I am describing regarding that big thread is part of the S1's code.

You don't have any of the source code in front of you so it's unlikely you are going to know what code is triggering what or where it is. Anyway please post screenshots and videos I suggest. BTW you aren't the only developer here

What do you want to know exactly and how will it help? I have several mixing sessions with dropouts and CPU meter kissing the max. And I have no issue regarding DPC.

There are no Presonus developers here. This is a user forum.

A demonstration song allows you/us to isolate/demonstrate an issue.
3rd party plugins are out.
Anything beyond what is necessary to demonstrate the issue is a waste of time.

If that occurs it will be brought to their attention.

For the second time.

1 core at 100% + all the others at 20-30% on average: how can Studio One not use these other cores judiciously?
It uses them as needed for the tasks

Why having multicore CPUs if Studio One cannot take advantage of them?
It does.

And also the one that intrigues me the most: how does it happen that each time I'm experiencing a maxed out CPU gauge and dropouts, there's always *one* and only one single core that is maxed out?

Too complex to answer without a demonstrable on more than one system use case.

soupiraille wroteWhat do you want to know exactly and how will it help? I have several mixing sessions with dropouts and CPU meter kissing the max. And I have no issue regarding DPC.

I thought I wrote most of this earlier.
Videos
Screenshots of latencymon (Inc Device by DPC).
Screenshots of process explorer showing full overview of system.
Screenshots of your project.
Screenshot of services running.
Screenshot of startup apps.
Other stuff, what antivirus you are running, what your BIOS settings for performance would be good as well.
Etc.

SMcNamara wroteIf it's not significant trouble, could someone give a list of what they consider the "non-essential services"? And for those of us who only connect to the internet for updates to software, can some of the networking services be put on either Manual, Manual (Trigered) [whatever difference that is], or Automatic (Delayed Start)?

Thanks,

Steve

Hi Steve. That's a good question.
Although the 'Black Viper' config guides are written by a gamer, the recommended services that you can disable or set to manual are a good place to start for a Windows DAW computer. This one is for Win 10 -

http://www.blackviper.com/service-confi ... gurations/

Obviously every user has different configs and different use cases, so approach this with caution. One size does not fit all.
Disable one service at a time though, so that you easily re-instate it if it does cause an issue.

Hope that helps.

soupiraille wroteHi. Actually if you look at the call stack you see that what's consuming CPU is not the driver but plugin processing, and there's a lot plugins being processed/running their code on this thread. I hope you're less confused!

But the thread you have highlighted (Thread ID 10920) in the screen-shot is only showing CPU utilisation at 2.25% -



Sorry, I'm no wiser as to what your screen-shots are demonstrating.

PreAl wrote

soupiraille wroteWhat do you want to know exactly and how will it help? I have several mixing sessions with dropouts and CPU meter kissing the max. And I have no issue regarding DPC.

I thought I wrote most of this earlier.
Videos
Screenshots of latencymon (Inc Device by DPC).
Screenshots of process explorer showing full overview of system.
Screenshots of your project.
Screenshot of services running.
Screenshot of startup apps.
Other stuff, what antivirus you are running, what your BIOS settings for performance would be good as well.
Etc.

Yes, I provide this and then what happens?
It won't help a bit, I know all this stuff you are talking about.
You are right though, I should have mentioned more details on my setup on the original post. My system is absolutely free of any unwanted, suspect or unnecessary programs, I have no BIOS configuration issues, no DPC issues, I myself selectively built, configured and tested my system. Everything is under control. All the control routines that you mentionned, I went through them. Thanks for helping though.