DAW Performance Optimizations

[azslow3]

21 hours ago, Blades said:

  Notably, setting the USB no-suspend thing in the power options (even with Ultimate option, this wasn't set)...

You are right, not there by default... Now I have to check what else I have manually changed, so I can do that again when needed... ?

[msmcleod]

On 12/30/2020 at 4:58 PM, John Vere said:

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 

FWIW my new RME Digiface USB is recording 32 simultaneous channels over USB 2 absolutely fine. That's both at 48K and 44.1K. As it's an ADAT based interface using 96K would just halve the number of channels available, so there'd be no difference in the amount of data transferred.

The Digiface is bus powered, but it's only powering 8 x ADAT ports and a headphone socket. There's no other I/O.

[Bruno de Souza Lino]

On 1/2/2021 at 6:17 PM, John Vere said:

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 

 

Expecting everyone to have current or similar hardware is a dangerous assumption to make. One example would be Spleeter. It makes use of TensorFlow to work, but their initial build assumed everyone using the software had nVidia graphic cards, and TensorFlow was compiled with CUDA support enabled. Many people with AMD cards couldn't use the product unless they compiled TensorFlow from source without CUDA enabled. After that was fixed, many people started complaining that Spleeter wouldn't work and there were a whole bunch of errors. The developer didn't say anywhere that Spleeter doesn't work if your CPU doesn't have AVX instructions. The Appleseed Blender render did a similar thing with SSE4.1 but it just crashed Blender during rendering instead of throwing an error.

There's also the argument of maximum performance. Not having things like internet on while you work or disabling some services could be the difference between being able to run one extra instance of that plugin or having to increase your latency samples. Windows will use all the resources from your machine it can to do its tasks without your permission and that's not the lack of control over my hardware I wish to have.

As better as ASIO drivers are nowadays, USB still is a serial bus. If you have a device that's slower than your interface on the same bus, the controller will run everything at the speed of the slowest device in the bus and there's nothing you can do about it except for making sure your interface has its own bus and nothing else uses it. I'm yet to see a PC + USB interface combo that can match a PC + RME Hammerfall HDSPe combo. With the latter and a sufficiently fast PC, you can quite comfortably run under 1 ms of latency with little to no performace hit.

[Mark Nicholson]

Is there any diagnostic software that can reveal the actual speed of the USB buses and which devices are setting the bus speed?

[Glenn Stanton]

there's a limit to the testing that can be done without some loopback on the USB port(s). there is one from Microsoft https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-usb-test-tool--mutt--devices but it requires loopbacks. the same for PassMark etc. otherwise it seems like most tests are skewed to disk performance. not sure if someone clever wrote a USB test using a audio interface as a loopback, although the REW app does use for defining the IO hardware baseline calibration.

in general, LatencyMon is the utility most likely to identify an issue and perhaps, unchecking hardware acceleration on the IO could help (if it has HW acceleration...). 

[azslow3]

3 hours ago, Bruno de Souza Lino said:

As better as ASIO drivers are nowadays, USB still is a serial bus. If you have a device that's slower than your interface on the same bus, the controller will run everything at the speed of the slowest device in the bus and there's nothing you can do about it except for making sure your interface has its own bus and nothing else uses it.

I guess in case that is true, my old 8x8 USB2 interface couldn't work on it's lowest settings when connected to 10m USB hub in parallel with  several USB1 devices. But it works.  USB specification deals with different standard/speed devices much better then making everything slow. ?

Also under 1ms RTL is never "comfortable". Computer should be top optimized and plug-ins carefully selected. Yes, there are no USB interfaces with such feature. But 3.3ms is really usable, with USB2 and moderate buffer size. In practice, the difference can be rarely perceived (taking into account that moving your head 30cm in any direction change latency by 1ms...).

[John Vere]

People and possibly the manufactures are obsessed with RTL specs. What does it matter if you track using direct monitoring? I think stability is way more important to me. 

Lower RTL is only needed if you want to use things like Guitar SIMS playing live in real time. 

My system had a reported RTL of 27 or so for most of the last 12 years. It's only recently down to 9ms.  I have always kept my buffers at 256 and everything always sounds great.  And because I have always used direct monitoring I experience bang on timing as I play.  

Funny story about the real world latency situation. As a bass player I always felt I played tighter with the drummer if I stood right there next to the kit. I'd often have one leg right in front of the kick drum. When I first started recording ( analog days) I found I could not get that bass to lock in to the timing unless I put the studio monitor next to my ear or used headphones.  So to me that 5ms delay when you are ? feet from the speakers/ monitors counts. 

For live music one huge benefit for modern performers using In ear monitors and not much talked about, is no more latency on stage.  

[Bruno de Souza Lino]

18 hours ago, azslow3 said:

I guess in case that is true, my old 8x8 USB2 interface couldn't work on it's lowest settings when connected to 10m USB hub in parallel with  several USB1 devices. But it works.  USB specification deals with different standard/speed devices much better then making everything slow. ?

Also under 1ms RTL is never "comfortable". Computer should be top optimized and plug-ins carefully selected. Yes, there are no USB interfaces with such feature. But 3.3ms is really usable, with USB2 and moderate buffer size. In practice, the difference can be rarely perceived (taking into account that moving your head 30cm in any direction change latency by 1ms...).

That's because some PCIe lanes speak directly to the CPU by means of CPU interrupts. The same can be talked about PS/2 vs USB.

 

17 hours ago, John Vere said:

People and possibly the manufactures are obsessed with RTL specs. What does it matter if you track using direct monitoring? I think stability is way more important to me. 

Lower RTL is only needed if you want to use things like Guitar SIMS playing live in real time. 

My system had a reported RTL of 27 or so for most of the last 12 years. It's only recently down to 9ms.  I have always kept my buffers at 256 and everything always sounds great.  And because I have always used direct monitoring I experience bang on timing as I play.  

Funny story about the real world latency situation. As a bass player I always felt I played tighter with the drummer if I stood right there next to the kit. I'd often have one leg right in front of the kick drum. When I first started recording ( analog days) I found I could not get that bass to lock in to the timing unless I put the studio monitor next to my ear or used headphones.  So to me that 5ms delay when you are ? feet from the speakers/ monitors counts. 

For live music one huge benefit for modern performers using In ear monitors and not much talked about, is no more latency on stage.  

Sure. Any latency below 5 ms is considered real time by human ears. In reality, we have much more latency that that. Humans can cope quite comfortably with up to 40 ms of latency depending on scenario and you get 1ms of latency for every foot your ears are away from the sound source. If you're playing 10 feet away from your bass amp, you're already dealing with 10 ms of latency.

[Starship Krupa]

I'll chime in and say that I always leave my hardwired or wi-fi connection enabled as I have found this to have no impact whatsoever on audio performance or dropouts on modern-day systems. When I run Latency Monitor or other performance measuring tools, the NIC drivers are way down the list of impactful interrupts. It's not necessary for me to turn my network connection off and back on every time I want to do DAW work.

The optimization that has had the largest impact on performance in Cakewalk is disabling realtime malware scanning for the various folders where Cakewalk does most of its reading and writing of files. On systems I configure I exclude the Cakewalk projects folder, plug-ins folders, and Cakewalk program directory. On my own systems I have disabled realtime scanning entirely, but I realize that's not an option for some.

The reason this has such an impact is because when Cakewalk is playing back audio, it streams it from the disk every time, and that includes muted takes and tracks. The only way to keep an audio file from streaming in a project is to archive the track it's in. And without disabling realtime scanning, every time Cakewalk uses the disk, whatever file it reads or writes will be run through the anti-malware software's scanning program.

[Noel Borthwick]

Could any of you folks running high core count PC’s please try the latest hot fix? ESP those running AMD Ryzen systems.
There are some optimizations and fixes for MMCSS that might improve performance. If nothing I just want to make sure that it doesn’t cause any issues.

[eric chevrier]

my 8 core Amd is running much better with this hot fix seems more stable !! I am using process lasso as well my computer isnt that high ended but seems to have a more stable run this is running buffers bar 23.2 16 tracks some instruments and plugins processer running at 18%

Edited January 30, 2021 by eric chevrier

[Noel Borthwick]

Hi @eric chevrier,

Is this an 8 physical core 16 virtual core PC? Can you provide some more detail on what you saw before this update? Are there fewer missed buffers at lower latencies? Also try with plugin load balancing off and on.

@Blades, @Glenn Stanton do you see any difference in this release?

[Glenn Stanton]

i'm only 4 core i5 CPU but i would say it's all stable and performing well - the performance meters on a project that was probably 30% is down a bit using the same plugins. i'll run some more definitive tests tomorrow.

[eric chevrier]

Hi Noel i have 8  physical cores running process lasso at high performance at 4100k sampling rate 16 lasso processing 13 to16% processer used 20% memory performance on daw  system performance11to16% engine 25to27% with plugin load balance on --- with 96000k 5.8msec 256 samples plugin balance off processer lasso 13to15% 100% responsive 20% memory load daw system 12to17% engine 27to29% buffers 0 plugin load balance on or off did not seem to make a difference i will try useing 96000k on a new project and push it hard and let you know if i see a big difference thanks Eric   i hope you can make sense of this

Edited January 31, 2021 by eric chevrier

[Glenn Stanton]

so some more testing - a project with 26 mostly active tracks, 25% of them with effects like EQ or compression. 16 busses - all with EQ, 5 w/ compression, 5 w/ reverbs and delays.  Dell 3521 A16, W10 20H2 19042.746, Intel Core i5-3437U 1.90GHz, 8GB, 2x SSD, Q802USB, CbB 2021.01 build 098

pretty much running @ 35-45% CPU, very even, no dropouts etc.

running ASIO4ALL 2048 samples

running @ 512 samples (10.7ms) roughly 10% more CPU than previous

same project - using WASAPI Exclusive 2044 samples (11.4ms)

going down to WASAPI 557 samples - a lot of crunching and drop outs - CPU were up 75-80%

using WDM/KS it's similar results to the ASIO4ALL. in essence for this project (a bit heavy) going up to 2K plus samples on WDM or ASIO4ALL - smooth as silk. WASAPI lower samples - not so much especially shared mode.

 

 

[eric chevrier]

wdm runs lower then asio 5-6% at 96000k 5.8 msec 13.8 round trip

[eric chevrier]

wdm runs lower then asio 5-6% at 96000k 5.8 msec 13.8 round trip

[Jim Hurley]

On 1/28/2021 at 6:02 AM, Noel Borthwick said:

Could any of you folks running high core count PC’s please try the latest hot fix? ESP those running AMD Ryzen systems.
There are some optimizations and fixes for MMCSS that might improve performance. If nothing I just want to make sure that it doesn’t cause any issues.

This project is one of several that I use to test for dropouts and performance issues. I have a 9900K running at 5.1 gHz.

I set the buffer to 144 samples at 48kHz and I run the WASAPI exclusive drivers using the 64-bit double precision engine, Pow-r 3 dithering.

The project uses 20 instances of MassiveX using a brutal preset and 64 notes (voices).

I don't see any issues at all.

 

[MediaGary]

On 1/28/2021 at 9:02 AM, Noel Borthwick said:

Could any of you folks running high core count PC’s please try the latest hot fix? ESP those running AMD Ryzen systems.
There are some optimizations and fixes for MMCSS that might improve performance. If nothing I just want to make sure that it doesn’t cause any issues.

Can you offer a standardized CbB project that we can all use for comparison?  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.

[Noel Borthwick]

Yes we used to have a test project we used several years ago. But I’m more interested in real world feedback of whether there is a perceptible improvement with fewer glitches in this version.