View Single Post
Old 28th March 2017
  #7
Lives for gear
One more possible cause of higher then anticipated CPU utilisation, dropouts, etc, which would apply in any DAW.

----------------------------------------------------------

Simple yet difficult to deduce. On further thought, this could happen in any DAW on all operating systems... Windows, Mac OS/OSX, Linux, and is completely driven by user error.

In my case my USB Audio Interface - Latency and drop outs challenge is 100% resolved.

Prior to now, I had attempted to find ways to route MME/Wasapi (windows audio) and mix it with the outputs of my DAW, cos my USB interface does not provide such an elegant mixer, which led to all kinds of inelegant solutions, routing audio through multiple instances of the DAW via local broadcast IP(Internet protocol).

I discovered today - via a Eureka moment - or moments, that the source of all the latency challenges which I had experienced with my DAW and Audio Interface on Window 10, were primarily due to user error - all mine.

I'll explain.

I had been monitoring my audio inputs via the DAW, through a fairly heavy set of reverbs, analog emulation plugins, track effects and additional monitoring effects.

Through a very fortunate set of events, I discovered my error, while monitoring another channel which had only a few monitoring effects in the path and my DAW's Interface CPU meter immediately indicated significantly lower CPU usage.

Monitoring with a heavy chain of plugins places more strain on the CPU, in real time.

In my case

Lesson learned - we are able do do things that many only dreamed of - monitor via a USB interface - with no discernible latency, via the DAW, with effects. But it needs a new mindset to avoid turning opportunity to a self inflicted nightmare. Once I reduced the number of effects in my consolidated record monitoring chain, I have since been able to simultaneously:

1. Playback Youtube video into my DAW

2. Record outputs into the DAW

3. Monitor A and B

4. Run at @ 44.1K down to 256 samples buffer, which meets my needs, all things considered, on a fairly vintage USB audio interface - EMU 0404 USB

5. No drop outs - will keep monitoring.

6. And I can watch/listen to as many streams of audio/video via my web browsers tabs, as my memory can load.

All is well, thought it good to share my learned lessons.

For those who do not have multi-client drivers, which is the case with the EMU 0404 USB, do take a look at VoiceMeeter Banana, which is an incredible mixing engine, although the documentation is a bit terse, but it does work and allow you to mix Windows audio (MME, WASAPI, etc) and pass this into an ASIO input stream through your DAW(optional) and mix the output from your DAW, with Windows Audio and inputs from your audio device, similar to tools like RME's Totalmix. An elegant and very stable solution

PS, I've taken the liberty to turn off the paging file in Windows 10. I prefer the operating system to let me know when memory is at a premium, which it graciously does, when its about to run out of memory, and I can date corrective action, by closing some browser tabs or other software.

Never thought I'd say this, but Windows 10 rocks, and my plan B to migrate to a turbocharged Mac Pro, is on hold, for now. I am more likely to migrate to a more powerful desktop/workstation also running Windows.

For now, Thunderbolt is definitely not required cos USB works well enough. 96K needs extra buffers but I can live with that, I'll record at 44.1 or 48 and mix at 96K, with extra buffers.

My Config

1. I'm on Windows 10
2. i5 laptop
3. I leave my Wi-fi enabled and Network, it makes no difference to the performance, now that the real issue has been resolved.
4 8GB RAM
5. I did disable the onboard sound card, not sure if this had any impact. I do not use it anyway.
6. Audio Interface - EMU 0404 USB, works well on all my USB ports USB2 or USB3.

It's only fair that having been quite vocal about my opinion on the challenges of navigating the interworking between hardware, audio device, and Windows manufacturer's, I can report that inadvertently the error was mine all along.

Of course I also did a number of the Windows 10 DAW optimisation tweaks - too many to list again here, but I think the aforementioned use of too many effects in the monitoring chain, was the 80 of the 20, the single most significant cause of the extraneous latency, when monitoring.

I think its important to highlight this cause its a new one to me, makes absolute sense, and a very easy error to make, and furthermore - hitherto, I have not heard it mentioned as a possible cause of latency challenges in all the write ups and advisories that I have come across.

Simply by turning on monitoring in a track where the audio is routed through effects down the audio path, places a higher demand on the processing hardware/USB , than if you were simply playing back the project. This higher demand is somehow made significantly worse, when the DAW needs to mix input into outputs through a huge chain of all these plugins which could be inserted or an auxes, or on the master, or in a monitoring chain - for DAW's which have a provision for monitoring effects that are not included in the mixdown.

Once you turn off monitoring, or reduce the number of effects in the monitoring audio routing (turning off insert plugins except maybe low CPU zero latency comfort reverp, on sends, grouping, sub grouping, etc), the CPU/USB interrupt demands reduce..... and gone are the glitches...

It's so easy to make this mistake, if you overdub after you have already placed effects on in the processing chain.

Special mention of Reaper's performance monitoring tool which gave me both the overall CPU load for the playback as well as the monitoring/record chain, as two separate related but distinct values, and really enabled me confirm that I had found the root cause of the unusually high CPU utilisation for the monitoring chain, and fixed it.