DAW Performance Optimizations

[Bruno de Souza Lino]

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 February 1, 2021 by Bruno de Souza Lino

[MediaGary]

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. 

[Glenn Stanton]

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 February 1, 2021 by Glenn Stanton

[Bruno de Souza Lino]

7 hours ago, Glenn Stanton said:

and other include VI synths

CbB doesn't have any VI synths. You only get TTS-1 and the Studio Instruments.

[Pete Brown]

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

[Noel Borthwick]

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.

[Starship Krupa]

On 2/1/2021 at 6:46 PM, Bruno de Souza Lino said:

CbB doesn't have any VI synths. You only get TTS-1 and the Studio Instruments.

If those are not "VI synths" what do you consider them to be? "VI ROMplers?"

[Bruno de Souza Lino]

On 2/25/2021 at 10:20 PM, Starship Krupa said:

If those are not "VI synths" what do you consider them to be? "VI ROMplers?"

TTS-1 is a GM Player
Since all the SI stuff uses samples, they are samplers.

A VI Synth would be something like Dexed.

[Starship Krupa]

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.

[lapasoa]

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.

[Jeremy Oakes]

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

[Pete Brown]

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

[Jeremy Oakes]

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