Jump to content

DAW Performance Optimizations


Blades

Recommended Posts

13 hours ago, MediaGary said:

Perhaps a beastly combination of linear phase EQ's, synth/patterns, and other heavy stuff to stress performance the aspects that you'd like to explore.

You mean, using all the stuff that doesn't come with CbB but comes with SONAR? How would people that don't have access to these even test it on their systems?

Edited by Bruno de Souza Lino
Link to comment
Share on other sites

1 hour ago, Bruno de Souza Lino said:

You mean, using all the stuff that doesn't come with CbB but comes with SONAR? How would people that don't have access to these even test it on their systems?

No, I actually didn't think it through to check whether the LP EQ was standard or not. I just remember it being a 'heavy' plugin.

My intent is for the test project to be based on an unadorned/vanilla version of CbB so that everyone can participate and we can have valid comparisons between machine configurations. 

Link to comment
Share on other sites

probably need to create a test template (bundle likely) with stock plugins and using various sweeps etc to exercise across a variety of conditions - EQ, compression, reverb, delays, saturation, modulation, levels, pans, tempo changes, automations, groove clips, etc.

maybe a bunch of the Pro Channel, SI and other include VI synths, and Sonitus plugins, REW (or other) full spectrum sweeps, noise, and reversed, and say 30 tracks, 5 aux busses, 6 busses, and one set of WAV files for 44.1K@16bit, 48K@24bit, and 96K@32bit clips.  loop over say 30 seconds - so there is "settle" time. maybe some marker bursts ever 5 seconds - 1K@-18db.

and for extra pain, an academy leader-type video clip that repeats 3x (10 seconds per). that way the complete package for a given test template would be something manageable in size but truly painful on a system ?.

Edited by Glenn Stanton
Link to comment
Share on other sites

  • 4 weeks later...

The "prefer background processes" bit can actually hurt you. During the investigation for my tweak list, I looked this one up, because it comes up often.

That setting is primarily for servers with background processes (think Database or web server) which need to be prioritized over the interactive applications. Normally, foreground apps get a boost to keep them responsive. Setting it to prefer background services puts foreground and background on a fairly equal footing, with some caveats.

For DAW use, when using an ASIO driver setting it to "background services" :

  • If the driver is loaded by a process other than the DAW (like a service), and doesn't use MMCSS threads, this setting could potentially keep the audio driver from being starved by a faster interactive application.
  • If the driver is loaded in-process with the DAW, this will not have any positive effect because the audio driver is part of the foreground application process.
  • If the driver is loaded by another process (like a service), and DOES use MMCSS threads, this setting will not have any positive effect.

In all cases, when you set this to prefer background processes, you are causing all those other services that folks put in tweak lists as "robbing" processor cycles, on an equal footing with your DAW app, causing them to potentially use more CPU than you may want.

If you are using WASAPI, the calculus is a bit different because there are more moving parts.

And, again, if the bit running in the background process is using MMCSS threads (many do now), this will not have any impact because those have a different scheduling algorithm applied.

As I mention in my on tweak list, the key is to measure measure measure. And be sure to do so both before and after the change, and in isolation from other changes. In most scenarios, this setting is not going to help performance of the DAW. In some cases, it could make it perform worse.

Pete

  • Thanks 4
Link to comment
Share on other sites

28 minutes ago, Pete Brown said:

The "prefer background processes" bit can actually hurt you. During the investigation for my tweak list, I looked this one up, because it comes up often.

That setting is primarily for servers with background processes (think Database or web server) which need to be prioritized over the interactive applications. Normally, foreground apps get a boost to keep them responsive. Setting it to prefer background services puts foreground and background on a fairly equal footing, with some caveats.

For DAW use, when using an ASIO driver setting it to "background services" :

  • If the driver is loaded by a process other than the DAW (like a service), and doesn't use MMCSS threads, this setting could potentially keep the audio driver from being starved by a faster interactive application.
  • If the driver is loaded in-process with the DAW, this will not have any positive effect because the audio driver is part of the foreground application process.
  • If the driver is loaded by another process (like a service), and DOES use MMCSS threads, this setting will not have any positive effect.

In all cases, when you set this to prefer background processes, you are causing all those other services that folks put in tweak lists as "robbing" processor cycles, on an equal footing with your DAW app, causing them to potentially use more CPU than you may want.

If you are using WASAPI, the calculus is a bit different because there are more moving parts.

And, again, if the bit running in the background process is using MMCSS threads (many do now), this will not have any impact because those have a different scheduling algorithm applied.

As I mention in my on tweak list, the key is to measure measure measure. And be sure to do so both before and after the change, and in isolation from other changes. In most scenarios, this setting is not going to help performance of the DAW. In some cases, it could make it perform worse.

Pete

Or worse it could appear to make it better in some very isolated circumstance and hurt performance in other cases. This is how a lot of these myths originated and people blindly follow them.
The other more recent thing that is being propagated is that MMCSS should not be set by the DAW and only by the driver. This has led to problems with drivers that are not coded properly to check for error codes. It would be great if the MMCSS documentation could explain the use cases better so that developers don't make mistaken assumptions.

  • Like 1
Link to comment
Share on other sites

On 2/1/2021 at 6:55 AM, MediaGary said:

My intent is for the test project to be based on an unadorned/vanilla version of CbB so that everyone can participate and we can have valid comparisons between machine configurations.

In this time of "roll your own Platinum," there are plenty of 3rd-party freeware plug-ins that have presets that can load a system. A|A|S Swatches on a Chromophone patch with many layers and long releases can get greedy on sustained chords.

I'd love to have a standard test project to play with, test the limits of a system, test the impact of different thread scheduling models, load balancing. While I get Noel's point about "real world" performance being the last word, there can be so many variables with edits, numbers of audio takes, plug-ins, some features like stretching and audio snap used or not. Also the possibility of file corruption.

Link to comment
Share on other sites

8 hours ago, lapasoa said:

We must also keep in mind that in every country there are companies that build computers expressely  to make music.

They are computers for  home recording and for professional studios too.

Then why do we get so many posts that have so little to say other than disagree with the pros ( see the Noel  and Pete Brown posts) ? It becomes very tiring.

J

Link to comment
Share on other sites

On 2/28/2021 at 4:52 PM, Jeremy Oakes said:

Then why do we get so many posts that have so little to say other than disagree with the pros ( see the Noel  and Pete Brown posts) ? It becomes very tiring.

J

Not quite sure what you're saying there. I don't generally disagree with the pros. But the DAW builders I know and work with have very specific configurations of hardware and software that they support.  In at least one case, the PCs are locked down like appliances, and the customers are not allowed to install anything else on them other than plugins. The tweaks they do for that aren't necessarily ones that should be up on a general list.

Pete

  • Like 1
Link to comment
Share on other sites

17 hours ago, Pete Brown said:

Not quite sure what you're saying there. I don't generally disagree with the pros. But the DAW builders I know and work with have very specific configurations of hardware and software that they support.  In at least one case, the PCs are locked down like appliances, and the customers are not allowed to install anything else on them other than plugins. The tweaks they do for that aren't necessarily ones that should be up on a general list.

Pete

We’re mixing things up here, i was referring to you as pro (and of course Noel). The info you provide is invaluable. There is a lot of confusing other info around

J
 

 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...