jpettit wrote1 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.

Jpettit, these were rhetorical questions...

I hear you jpettit, but Ain't Ari close to the dev team? He is pretty active here and on Facebook. I don't want to argue but it does seem that directly or indirectly the dev team has an eye on the forum and the Facebook group...

Yes Ari is in QA and post the releases here.

I am giving you the best adice in terms of having a useful conversation here or the not.

I got your point jpettit. No worries I'll try to provide a relevant test song to reproduce what I'm experiencing.

Ari actually does more than posting releases. He even responded to some people in the thread I created on Facebook. What is odd though, is that he never responded to me; in my own thread he responded to other's comments, but never to me, never to the original post nor to the direct questions I was asking him. In my own thread. That's weird but there must be a reason for this... Anyways, on to that test song.
(It's not a blaming statement. Actually I have respect for Ari.)

Thanks jpettit for helping.

You are mixing FB and this forum.

Let’s just step back and think about it.
The developers have more that 100 years of combined experience with designing real-time audio applications on multi core systems.

There are trade offs and games that can be play from one DAW to the next. They are aware of all of them.

They made significant performance improvements in 3.3

They will continue to make improvements but keep in mind they typically involve trade offs.

You are not going to get an answer from them here or on FB.

You can work with test cases and benchmarks between peoples systems and other DAWs that highlight the trade off differences.

soupiraille wrote

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.

If we are just supposed to take everything you say at face value and you aren't prepared to clearly demonstrate, as we might be able to see something you may have missed for instance, then really that is stalemate and the discussion is a bit of a waste of time imho.

Anyway good luck resolving your problem.

Don't take it like that. I said I would try to create a relevant test song in order to analyze the situation. If you read well my original post, what I'm pointing out is a CPU bottleneck occurring in one single thread, there's one single thread that seems to do too much work, and that one thread is created withing Studio One's code. What I wanted to bring the attention on, is not the dropouts I get but rather this.

Morticia wrote

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.

Thanks very much, I'll look into it.

Steve

Hi all,

Here’s what I did to reproduce the issue described by soupiraille.

My system: Mac Pro 6,1 (2013 Trashcan), 4 cores, 16 GB Ram 1 TB internal SSD, MacOS 10.12.6 (Sierra). S1 3.5.4, Device Block Size set to 1024 samples, Dropout Protection to High (also 1024 samples). I am going for maximum performance here, not low latency.

The steps:

Create a single audio track (Audio 1) in S1 and load an audio file. In the mixer, add a bus channel (Bus 1) and route Audio 1 channel to it. Add another bus channel and route Bus 1 to it.

Load a plugin that is really heavy on the CPU into Audio 1 channel. None of the stock plugins will do IMO, the performance meter has to show something, preferably at least 3-4% of usage. In my case I used Ozone 8 loaded with six processors: Vintage Tape, Dynamics, Spectral Shaper, Vintage Compressor, Exciter, Maximizer.

Copy the loaded plugin to Bus 1, Bus 2 and Main Bus. Notice how the S1 performance meter shoots upward. Im my particular case to almost 60% of usage. From just four plugins.

Turn off the plugins loaded into busses. Duplicate Audio 1 track three times (duplicate complete). There are now four audio channels with one instance of the original plugin (in my case Ozone 8) loaded in each. On my system, the same four plugins are now reported by S1 to only consume 13% of CPU power. When no busses are involved.

To check that this isn’t simply some Ozone issue I reran the original project (with one audio track and two busses) but this time using the TDR Slick EQ M plugin with all the bands enabled and set to “Insane” performance mode. The result was similar.

The conclusion? Using plugins on busses in S1 comes with a huge CPU hit at the moment. At least that’s how it is on my machine. The more busses there are nested within each other the worse it gets. Quite a big problem, I’d say. There is no way the developers at Presonus are not aware of it. There is also no way they are not working on a solution. When will that solution arrive and how effective it will be, that is the real question here.

They are always working on it.

Please try to create two test case files and attach them.
1) Only S1 native plugins or instruments (the simpler the better). This is used to compare one system to another.
2) Only use highly accessible (free or commonplace) plugins. This is used to compare one DAW to another.

I wanted to test this a little bit further so I created a project with 20 audio tracks, no virtual instruments to keep things simple, and no busses. The idea was to compare S1’s performance with that of Logic Pro X with no busses involved, just regular audio channels.

I loaded each of the channels with the same Ozone plugin (six processors) as described in my previous post, and, lo and behold, suddenly S1 can handle 20 very heavy hitting plugins with room to spare (total CPU at 62-63%). Then I started adding Slick EQ M plugins and was able to load 17 instances with clean playback, the S1 CPU meter at 92%, the load fairly evenly spread in the system CPU meter. That’s about the same performance I got from Logic, which is usually considered to be a solid player in that department.

So it turns out S1 actually performs pretty darn good — so long as busses aren’t involved.

To check this still a bit further I moved one of the Ozone plugin instances to the Main bus (so there was still 20 of them loaded) and started playback. Complete no go. I had to disable six — I’ll repeat that: six — Ozone plugins in the regular audio channels to be able to run one such plugin on the Main bus. S1 CPU was at 89%.

Finally, there is the MixFX, which exacerbates things further. With all other plugins on the Main bus turned off and only ConsoleShaper loaded, I was able to get clean playback with only 14 instances of Ozone 8 and the same number of Slick EQ M’s active. S1 CPU at about 75% and rather unstable. With CTC-1 it’s the same or worse, especially when using the Tube emulation which appears to be a real CPU hog. What’s more, merely turning MixFX off does not appear to help at all, it is necessary to unload the plugin completely to get the performance back.

jpettit wroteThey are always working on it.

Please try to create two test case files and attach them.
1) Only S1 native plugins or instruments (the simpler the better). This is used to compare one system to another.
2) Only use highly accessible (free or commonplace) plugins. This is used to compare one DAW to another.

As I said, I don’t think stock plugins would do any good here. They just don’t use enough CPU power to be able to judge what’s going on.

Also, as I said already as well, I don’t think any of this is news to the developers. I’m sure they are aware of everything that’s been said in this thread and then some. My posts are aimed more at the users, to help them understand the issue, so they can perhaps come up with some workarounds. Adjust their workflows. Maybe use less busses for the time being, especially if they are nested within each other. Or less processing on the busses. And not leave the MixFX plugins loaded, even if they are turned off. That kind of stuff.

A couple of things to point out about CPU usage:

1. I don't think this has come up in this thread, but always just want to remind people that Studio One's Performance Monitor shows the CPU usage of the mossed-stressed core only. It's not an average.

2. Having the low-latency monitoring mode on and a "Monitored" track will double the CPU usage for that track. Low Latency Monitoring mode creates a copy of the plugin chain behind the scenes and uses the lower buffer for armed tracks, resulting in a much higher CPU usage when a track is setup for input monitoring. If you're not careful, or have S1 set to automatically Arm and Input Monitor the selected track in combination with Low Latency Monitoring modes, you could be really doing yourself a big disservice when it comes to CPU usage.

3. Studio One will not balance instrument tracks or effects on an instrument track across multiple cores. They will end up in their own thread. So if you're running 13 tracks of BFD or Superior Drummer, with effects on each, and being monitored through a drum bus, that's going to end up on the same core.

4. Faster clock speeds = more effects per track, more cores = more tracks per project. That's an over-simplification, I know, but a 20 core PC with a 3ghz clock will max out one care faster than an 8 core PC with a 4.5ghz clockspeed. However, that same 20 core PC would run much larger projects if each individual channel wasn't being maxed out.

5. If you want to compare DAWs CPU performance, use all third party plugins, use the same buffer conditions/settings and recreate projects in both DAWs and make note of how many tracks you can run in 1) tracking scenario and 2) mixing scenario before you start hearing glitches. Test both independently since low latency performance modes may impact live recording and mixing scenarios differently.

Anyway, hope some of that is useful to some folks reading this thread.

Wow, I got some backup thank you very much franYo! I feel less alone.

You pretty much got it right, the track and bus routing you chose makes a huge difference regarding CPU utilization. The busing in Studio One create a bottleneck, concentrating the load on one particular thread (I said "thread", not even "core").

You are 100% right, the dev team understands all what have been said perfectly and know what it's all about. They know how to create such situations and debug it. I am also pretty sure that if Ari didn't say a word both here and FB while he is active on both, it's because he is thinking about it. Most likely.

Since I do not know exactly what role jpettit plays in the PreSonus sphere (I guess jpettit you are a simple user, but a user that can reach for some people at PreSonus, am I right?) then I will try to give him what he is asking, I really want this to be brought to the dev team. He said it will, so I'll do what he's asking even though I know the devs can easily reproduce the situation. :evil inside: (jpettit I am partially kidding, I know it is always better to provide a test material).

Basically I run in the same situation as you franYo, I think I will easily come up with a song with 3rd party plugins, but I'm not sure I will with only stock plugins (but don't jump on me jpettit! I said I'll try! ).

Thank you very much franYo for taking the time to reproduce the situation and for your excellent report. What I'm glad about is that you are on OSX while I am on Windows Which reinforces the facts that with pretty much no doubt it is an algorithm thing.

What to say? Well, thank you!

Funkybot wroteA couple of things to point out about CPU usage:

1. I don't think this has come up in this thread, but always just want to remind people that Studio One's Performance Monitor shows the CPU usage of the mossed-stressed core only. It's not an average.

2. Having the low-latency monitoring mode on and a "Monitored" track will double the CPU usage for that track. Low Latency Monitoring mode creates a copy of the plugin chain behind the scenes and uses the lower buffer for armed tracks, resulting in a much higher CPU usage when a track is setup for input monitoring. If you're not careful, or have S1 set to automatically Arm and Input Monitor the selected track in combination with Low Latency Monitoring modes, you could be really doing yourself a big disservice when it comes to CPU usage.

3. Studio One will not balance instrument tracks or effects on an instrument track across multiple cores. They will end up in their own thread. So if you're running 13 tracks of BFD or Superior Drummer, with effects on each, and being monitored through a drum bus, that's going to end up on the same core.

4. Faster clock speeds = more effects per track, more cores = more tracks per project. That's an over-simplification, I know, but a 20 core PC with a 3ghz clock will max out one care faster than an 8 core PC with a 4.5ghz clockspeed. However, that same 20 core PC would run much larger projects if each individual channel wasn't being maxed out.

5. If you want to compare DAWs CPU performance, use all third party plugins, use the same buffer conditions/settings and recreate projects in both DAWs and make note of how many tracks you can run in 1) tracking scenario and 2) mixing scenario before you start hearing glitches. Test both independently since low latency performance modes may impact live recording and mixing scenarios differently.

Anyway, hope some of that is useful to some folks reading this thread.

Thanks a lot funkybot for these reminders. I do hope too it will be useful to some folks reading this thread.

Concerning the CPU meter in Studio One, actually it seems more than what you say which is also what I wrote in the OP. Ari said it acts more like a dropout prediction meter, it makes relevants sums in the background in order to show the user how close to the "danger zone"(i.e. the dropout zone) he/she is.

Anyways thanks funkybot

soupiraille wroteSince I do not know exactly what role jpettit plays in the PreSonus sphere (I guess jpettit you are a simple user, but a user that can reach for some people at PreSonus, am I right?) then I will try to give him what he is asking, I really want this to be brought to the dev team.

As stated earlier they make a living out of working on this. They know exactly where the trade-offs are and are always working on improve it.

Thanks

Ok jpettit, then do you think what I am bringing to the table is absolutely no news and there's no way I can contribute to situation, or do you think it's worth handing the devs a test case which they could investigate on because they may not have seen certain aspects?

In other words: should I bother creating a test song (which will ask me some time to do, I am pretty much overbook in this period of time), or not.. If I can't help, why bother. You seem to say they perfectly know the situation I am describing in my OP.
Thank you.