DAW Performance Optimizations

[Blades]

I got a new computer.  I went through all of the basic stuff but was reminded of a few things that make the DAWs perform better.  So I made a blog post and video on it for others who are looking for a few QUICK tips on making their computer perform better.  This is not any kind of all-inclusive list of performance tips - just a few that make a big difference easily.

Check out the post here: https://www.blades.technology/music/daws-sonar-and-studio-one/three-tips-to-optimize-pc-for-daw-use

 

Edited December 30, 2020 by Blades

[John Vere]

Troubleshooting USB Audio Problems on Windows.pdf

I got this from Motu yesterday covers most things worth doing. 

[Billy86]

13 hours ago, John Vere said:

Troubleshooting USB Audio Problems on Windows.pdf 49.24 kB · 6 downloads

I got this from Motu yesterday covers most things worth doing. 

Always willing to try and boost data throughput performance, in this case USB port speed for my Focusrite 4i4 interface.  If it’s plugged into a 5Gbps USB port, is there a marked advantage to installing a PCIe USB card that has a  10 Gbps capability? If it helps to improve audio latency balancing act,  seems like an upgrade to consider.  Or, is latency unrelated to a faster USB connection?

[John Vere]

I was told the USB 2 is more than capable and that there was no advantage to “ faster” ports. That was a few years ago so might have changed.  
But the reason to use the PCI card is power not speed. Bus power sucks  just try and run 2 phantom powered mikes with that.  
im going to order a USB card myself after reading that document and see if that gets rid of my glitching at 256 buffers.
It makes sense that my  Scarlett doesn’t glitch it uses a power supply the Motu is glitchy due to crummy bus power 

[MediaGary]

Latency of USB ports is *practically* unrelated to its speed in Gbit/sec. 

You will find that USB 2.0 and 3.1, 3.2 in all its flavors have latency figures that are all clustered around what the driver suite is able to accomplish.  Each vendor has its own device driver implementation, and that is a strong predictor of what you'll experience/measure.  Also, as you know, a USB 3.x port will 'downshift' to run at USB 2.0 speeds when presented with a USB 2.0 device.

Also keep in mind that PCI is less than 1.1Gbit/sec, and that PCIe interfaces tend to be just one PCIe lane.  Usually that's a PCIe 1.1 lane, so 250MByte/sec or a net of 2Gbit/sec (payload after decode) is a common performance metric.  However, both PCIe and PCI have a vastly different and more efficient driver implementation, and therefore is able to achieve lower latency than USB. 

I've attached a chart I made a few weeks ago that summarizes the Round-Trip-Latency of all of the attachment methods that I've used with my Midas M32 and Behringer X32 mixers, both in Win10 and macOS.   To helps with the nomenclature of the chart: DVS is Dante Virtual Soundcard,  AES16e-50 is a Lynx PCIe card,  the DN9630 is a USB 2.0-to-AES50 adapter, the MADI interface is an RME PCIe ExpressCard, the LoopBk was direct ADAT-out-to-ADAT-in of an RME HDSP 9652 connected through an external box to a PCIe slot.  Lastly, X-ADAT is the way that RME 9652 card is connected through my Midas M32 that serves as the center of my studio.

 

Edited December 31, 2020 by MediaGary
Fixed Gbit/s typo

[Mark Nicholson]

Don't forget good old fashioned have as much memory as possible

[Blades]

@MediaGary Wow - that's a lot of detail!  Thanks for sharing this.  It's definitely important to show the subtlety in interfaces.  Whether you are using USB, PCI(e), or  even Thunderbolt, most modern interfaces can perform well enough for most people.  As always, chasing GAS is not always a recipe for better sounding songs or mixes.  

As I mentioned in the intro and the blog post, these are the few "most effective" or noticeable changes that I made to the system to get the DAW performing.  There are tons of guides out there for making your system work the best it can.  Specs are part of the battle, but configuration and system health play into that mix AT LEAST as much. 

[azslow3]

• tip with power plan is good. To be on the "safe side", there is also "Ultimate" power plan. Note that by default Windows is NOT showing all available (and so many relevant) options in power plan editor, so it is f.e. not possible to manually edit one power plan to another (there is registry tweak on github to show all options). Simple switching to properly constructed power plan covers all recommended (f.e. in mentioned MOTU pdf) settings. Also I have found on the fly switch https://www.microsoft.com/en-us/p/powerplanswitcher/9nblggh556l3 useful, since I use one computer for everything (no reason to keep it "ultimate" all the time).
• disabling WiFi, NVIDIA audio and in fact all other devices which are not in use is also good idea in general.
• but switching priority to background processed is not a good idea in general... Proper written drivers + proper written DAW RT part should take care about priorities. Sometimes priority to background helps, sometimes running DAW as background process also change the result. All that are dirty workaround. Obviously, we want the DAW get resources as quick as possible, except audio driver activity. F.e. we don't want Windows own scheduled tasks have priority over the DAW. It seems like the problem is with some audio drivers, which for some reason run something as background process. So once the DAW (heavy plug-in) use resources, the driver can't get required time slot in time. For me, that is the only reasonable explanation why shifting general priority can have positive influence. Note there are some "tools" which allow manually set priority to particular processes/threads and some people report that works.

I want to add one point, which I have noticed by occasion recently and it seems like that is not mentioned often:

• sharing driver between applications can drastically affect stable buffer size. I have checked with my M-Audio and Phonic. Both allow ASIO in parallel with other modes. Once the same device is open by other application (f.e. web browser is running), even in case that other application(s) is not producing any sound, small buffers start glitch in the DAW.

[Steve Harder]

3 hours ago, azslow3 said:

sharing driver between applications can drastically affect stable buffer size. I have checked with my M-Audio and Phonic. Both allow ASIO in parallel with other modes. Once the same device is open by other application (f.e. web browser is running), even in case that other application(s) is not producing any sound, small buffers start glitch in the DAW.

I agree with this.  If low latency is a very high priority I switch to exclusive.  But most of the time I can opt for the convenience of parallel on my multi-use PC.

[rsinger]

On 12/30/2020 at 8:08 AM, Billy86 said:

Always willing to try and boost data throughput performance, in this case USB port speed for my Focusrite 4i4 interface.  If it’s plugged into a 5Gbps USB port, is there a marked advantage to installing a PCIe USB card that has a  10 Gbps capability? If it helps to improve audio latency balancing act,  seems like an upgrade to consider.  Or, is latency unrelated to a faster USB connection?

What I've read is that usb 3.0/3.1 provides more bandwidth (you can have more channels), but doesn't improve latency. That's why we haven't seen a lot of new usb 3/3.1 interfaces. If you have other devices on your usb hub besides the interface it may help due to increased bandwidth/throughput.

[Billy86]

Thanks for weighing in everyone. I’ve got a decent i9/9900 system and maxed out RAM @ 64 Gb. I also run ParkControl, which prevents Windows from parking cores (which I understand it does by default), spreading out the CPU workload across all cores; in my case 8 cores/16 threads. This is what multi-core processing for plugins option does in CbB. ParkControl has always worked well for me, so I’ve stuck with it, and don’t run CbB load balancing  

.

 

[Blades]

but switching priority to background processed is not a good idea in general

@AzSlow3 - Interesting since this is the ONE thing that made an enormous difference in my system.  When not this way, my Waves plugins were completely unusable.

It's actually a fairly funny/sad story.  I work as the owner of a Technology company (business IT services).  I was talking with one of my technicians and joking that my system had been upgraded from Windows 7 to Windows 8 to Windows 10 and all of the baggage came along for the ride over the years.  I didn't actually realize how long it had been: from 2015 to 2020.  So I decided to rebuild.  Then I had a bunch of other "stuff" going on, so I hadn't been DAW recording and been more focused on doing YouTube video stuff.  So I imagine that I didn't do some of these tweaks to that interim system.  Come to last weekend and I'm getting this pop/click stuff going on in this new system - so frustrating.  And I reviewed past optimization stuff I did and got to this one.  And it (almost) completely eliminated the annoyance.

Every system and driver is different, I suppose.  I'm using a Presonus Studio 1824 USB along with Studio One (or sometimes Cakewalk).  I used to have an Echo Audio Layla 3G that I used for MANY years.  Honestly, it didn't really perform that much worse.  Being a PCI interface might have given it some benefit, but the old drivers were just problematic for me and the brand matching seemed like a logical idea to me - not to mention that the Presonus was effectively free to me since I sold some gear I wasn't using and never would and bought it with the proceeds.

Thanks for all the comments so far - off to locate that "Ultimate" performance option.

 

 

[Blades]

If you don't have the Ultimate Performance Power Plan available to you, go to an administrator mode cmd line or PowerShell and use this command:

powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61

Then go back to the Choose a Power Plan screen and you should see it there.

[azslow3]

17 hours ago, rsinger said:

What I've read is that usb 3.0/3.1 provides more bandwidth (you can have more channels), but doesn't improve latency. That's why we haven't seen a lot of new usb 3/3.1 interfaces. If you have other devices on your usb hub besides the interface it may help due to increased bandwidth/throughput.

USB 1.1 has sufficient bandwidth for 2x2. What make difference for audio interfaces between USB 1/2/3 / FW/ thunderbolt  is communication organization. F.e. USB is a bus with predefined  minimum for communication "cycles", and that minimum is relatively high for USB1 and USB2. That is the reason you can't find USB1-2 interfaces with latency (RTL) lower then some value (for USB1 is was quite big, with significant improvement in USB2). USB3/FW/TB/PCI(e) open a possibility to make it lower, which some interfaces use (down to 1ms).

So, USB3/TB can improve latency, when used properly on hardware and in drivers. But since USB2 can go down to ~3ms and lower latency requires very special system settings to work stable, the market is limited and so the number of such devices.

 

12 hours ago, Billy86 said:

Thanks for weighing in everyone. I’ve got a decent i9/9900 system and maxed out RAM @ 64 Gb. I also run ParkControl, which prevents Windows from parking cores (which I understand it does by default), spreading out the CPU workload across all cores; in my case 8 cores/16 threads. This is what multi-core processing for plugins option does in CbB. ParkControl has always worked well for me, so I’ve stuck with it, and don’t run CbB load balancing 

Disabling parking cores (in general disabling C state changes) is the way to bring down occasional system latency from ~250uSec to ~50uSec. Unfortunately that spread out significant heat (f.e. my i9 will constantly spread >=90W,).  Unfortunately that is the only way to work with sub 64 samples buffers and/or to bring possible CPU load closer to theoretical max without introducing audio glitches. But the price (in terms of noise or super-silent cooling system) is too high for an average user...

Plug-in multi-core processing in Cakewalk (as I understand it) is based on parallelizing processing after splitting audio buffer (that is why there is lowest buffer size with which it can be enabled), that effect can't be achieved with external tools.

[Noel Borthwick]

On 12/31/2020 at 6:42 AM, azslow3 said:

•  
• but switching priority to background processed is not a good idea in general... Proper written drivers + proper written DAW RT part should take care about priorities. Sometimes priority to background helps, sometimes running DAW as background process also change the result. All that are dirty workaround. Obviously, we want the DAW get resources as quick as possible, except audio driver activity. F.e. we don't want Windows own scheduled tasks have priority over the DAW. It seems like the problem is with some audio drivers, which for some reason run something as background process. So once the DAW (heavy plug-in) use resources, the driver can't get required time slot in time. For me, that is the only reasonable explanation why shifting general priority can have positive influence. Note there are some "tools" which allow manually set priority to particular processes/threads and some people report that works.

I want to add one point, which I have noticed by occasion recently and it seems like that is not mentioned often:

• sharing driver between applications can drastically affect stable buffer size. I have checked with my M-Audio and Phonic. Both allow ASIO in parallel with other modes. Once the same device is open by other application (f.e. web browser is running), even in case that other application(s) is not producing any sound, small buffers start glitch in the DAW.

Good points. A few driver vendors create dependencies that cause unpredictable realtime behavior. Ive had this discussion even with Roland who claimed that background processing was the proper setup. Its completely counter intuitive to me since its now allowing any background process on the system to be given take priority over the DAW which means that audio processing could get less resources in theory! I’ve even discussed this with a systems engineer at Microsoft many years ago who said it was not a good idea to do this in general. Maybe @Pete Brown could verify this.
Your theory that they have a (bad) dependency on some background process is possible. I’ve definitely seen drivers start to glitch when there is excessive activity on the UI thread - in theory this should NOT happen since the UI thread is running at much lower priority than the engine.
Cakewalk’s UI is on the heavy side and I’ve been chipping away at reducing its footprint all of last year so it has helped but in an ideal world this should not be an issue.

Regarding drivers that share this is likely because they are internally synchronizing to block processing until all clients have processed audio, similar to what WASAPI shared mode does because they have to mix all streams and potentially do SRC as well. Its not surprising that this scenario would cause some glitching. I wonder if the ASIO drivers that support multiclient access are running their mixing code in a different process. If so I could see how having background priority set could potentially change things there.

 

[Noel Borthwick]

4 hours ago, azslow3 said:

 

Plug-in multi-core processing in Cakewalk (as I understand it) is based on parallelizing processing after splitting audio buffer (that is why there is lowest buffer size with which it can be enabled), that effect can't be achieved with external tools.

Correct, it uses pipeline parallelism to split the buffers and process them in parallel to achieve greater parallel processing even though the DSP pipeline itself has serial dependencies.  I have a known limitation in the implementation that I hope to improve this year that may help improve performance when using it.

[Billy86]

2 hours ago, Noel Borthwick said:

Correct, it uses pipeline parallelism to split the buffers and process them in parallel to achieve greater parallel processing even though the DSP pipeline itself has serial dependencies.  I have a known limitation in the implementation that I hope to improve this year that may help improve performance when using it.

Great to know/understand. I’ll be enabling multi-core processing. Thanks. 

[Blades]

On 12/29/2020 at 8:50 PM, John Vere said:

Troubleshooting USB Audio Problems on Windows.pdf 49.24 kB · 25 downloads

I got this from Motu yesterday covers most things worth doing. 

Thanks John.  There were a few in here that I didn't do and hope to see some results from.  Notably, setting the USB no-suspend thing in the power options (even with Ultimate option, this wasn't set) and setting the 3D of NVidia card to prefer performance.  I have done so many tweaks trying to fix my old system that I forgot to apply a few on the new one, which was performing so much better anyway that I guess I thought I'd already done them!

[Bruno de Souza Lino]

Presonus has a very good guide on tweaking your Windows PC for audio. There should also be a Creative Sauce video on that.

[John Vere]

My observation is that generally a well behaved DAW will go hand in hand with the Quality of the ASIO driver supplied by manufacturers of interfaces. 
10 year ago USB ASIO drivers seemed to suck if you had a lower price interface.
And PC specs used to also matter. Notice that there’s no point asking “ What are your computer specs?”   anymore when troubleshooting someone’s issues. It will be rare to find someone with an under powered machine these days. And generally you can get away with breaking the rules we had 10 years ago like shut down the internet as it seems to make little difference with modern systems 
 

Seems most mainstream audio interfaces have good drivers now. And I’m impressed by company’s like Focusrite who upgrade drivers for their older units. Seems very few people have issues anymore and when we do they are that much harder to pin down