A little Confused�: Audio Crackling vs. CPU Usage

[dalpozlead]

I"m layering 4 instances of Roland Cloud"s System 8 into my DAW (REAPER), just found that this VST has a huge CPU usage (when triggering to play each instance uses ~25% of my Intel i7-6700 3.4GHz) which makes impossible to play the patch (99% CPU usage)⦠enormous audio crackling!

My doubt is because recently I"ve also experienced audio cracking when using Guitar VST with Neural DSP Archetype (when activating 2 instances to play together it"s almost impossible due to audio cracklingâ¦) but, in this case CPU usage remains ~25% in totalâ¦

Therefore my question is if one audio crackling (obviously due to high CPU usage) can be related to the same audio symptoms when CPU only reaches 25%.

Hope this is clear guys :-) thanks!

 

 

[Lady Gaia]

Many VSTs can't divide their work across multiple CPU cores. That means that on a quad-core CPU like yours you can't get close to 25% usage without gaps in audio resulting in the kind of crackling you're hearing. It's often confusing because a lot of tools that show CPU usage will show that each of the four cores is at 25%, which would seem to suggest that you could use more - but that's an illusion. In practice, one VST's work is being handed around round-robin style so that only one core at a time is doing any work (this is done to spread heat production around which helps the CPU stay running at higher clock speeds.)

 

Does that make sense, or am I misinterpreting your question?

[Docbop]

Lady Gaia is right and most app's aren't multi-threaded and rely on the OS to juggle the processes that can increase load on the CPU swapping processes in and out. Then memory is you don't have a lot then then processes then virtual memory is getting worked hard juggling memory which is more load on the CPU. So a lot of things come into play trying to troubleshoot processor being max'd out. That's why computers for audio need a lot of CPU and RAM as well as fast drives.

[dalpozlead]

Ok, so what I got from this is that independently of what the Task Manager indicates about my CPU I can still have sound drops (e.g. CPU ~ 25%)⦠maybe going for a Intel i9 should help me?

 

This only happens for CPU right? For RAM usage I should clearly see the gape between NEED vs. AVAILABLE.

[SamuelBLupowitz]

Many VSTs can't divide their work across multiple CPU cores. That means that on a quad-core CPU like yours you can't get close to 25% usage without gaps in audio resulting in the kind of crackling you're hearing. It's often confusing because a lot of tools that show CPU usage will show that each of the four cores is at 25%, which would seem to suggest that you could use more - but that's an illusion. In practice, one VST's work is being handed around round-robin style so that only one core at a time is doing any work (this is done to spread heat production around which helps the CPU stay running at higher clock speeds.)

I did not know this and it is hugely helpful information. Thanks for sharing.

[Devnor]

I"m layering 4 instances of Roland Cloud"s System 8 into my DAW (REAPER), just found that this VST has a huge CPU usage (when triggering to play each instance uses ~25% of my Intel i7-6700 3.4GHz) which makes impossible to play the patch (99% CPU usage)⦠enormous audio crackling!

 

4 instances of System 8 will bring 3.5Ghz 6 core trash can Mac to its knees. High buffers, ect nothing seems to help. It's the reason I ended my RC sub.

 

[dalpozlead]

I"m layering 4 instances of Roland Cloud"s System 8 into my DAW (REAPER), just found that this VST has a huge CPU usage (when triggering to play each instance uses ~25% of my Intel i7-6700 3.4GHz) which makes impossible to play the patch (99% CPU usage)⦠enormous audio crackling!

 

4 instances of System 8 will bring 3.5Ghz 6 core trash can Mac to its knees. High buffers, ect nothing seems to help. It's the reason I ended my RC sub.

 

Yeah , this seems a deal breaker for me also...

[Iconoclast]

Totally different system but I had an eerily similar problem with Mainstage that I've since blamed on insufficient video processing capability. In my case the video card could not be updated but I purchased a new computer with vastly improved video card and it went from unusable to bulletproof.

 

If your computer is handing off video tasks to the main processor you can get very short transient bursts of cpu usage that are coincincent with the pops/crackles? That's what I think I had.

 

I've seen a lot of smart people argue this back and forth from different sides, but that's my take on it.

[Lady Gaia]

The root problem is that we"re expecting our computers to meet hard real-time requirements (provide 48k samples every single second without fail, with as little latency as possible) but we"re using a general-purpose operating system that provides no such guarantees.

 

It"s like commuting to work. Leave with just enough time to get to your first meeting and you"ll be late on a regular basis (in this case a missed meeting results in an audio discontinuity that yields a crackle or pop.) Even if you give yourself half an hour longer than it should take, any number of circumstances can arise that delay you past that first commitment (snap, crackle.) You don"t want to leave too early because then you"re having to get up too early (think of this as audible latency between hitting a key and hearing sound.) The only way to guarantee you won"t ever have a problem is to sleep in your office (put the task on dedicated hardware that doesn"t do anything else.)

 

The ACB model Roland uses is stupidly compute-intensive, which is why they sell dedicated hardware that does the same job and even it only offers eight voices. It"s also why their newest offerings don"t use ACB and compromise on something a little less intensive so they can squeeze more voices out of affordable gear.

[Nathanael_I]

Lady Gaia is correct. There is a big difference between the overall CPU utilization at the strength of the real-time system. Kind of like torque and horsepower. They are related. But subtly different.

 

In our case, audio is different than most computer workloads. Most computer tasks are not real-time. They are "eventually" tasks. This is great for a modern OS. it means that the scheduler can constantly rotate hundreds(or thousands) of jobs through the CPU a second. All of them are happy and eventually get done. Audio is not like this. There is a buffer in your sound card. If It runs empty, you will get pops and clicks. So, the CPU has to service the audio threads regularly... more regularly than other threads. And indeed Windows and OS X both have priority lanes for multimedia traffic.

 

The thing is that audio is not like other work in other ways too. One of them is that audio doesn't parallelize well. Think of a channel strip. The processing occurs in a given order, one right after the other. This means that I can't break out part of the processing and put it on another core. Generally an entire instrument or channel strip has to execute on a single core at a time. Add in a bunch of bussing and submixes and this gets worse. It is very normal for heavily loaded DAWs to start crackling well below 100% utilization - often even 40-60%. This is why ProTools hardware exists (and other DSP hardware). It offers fixed latency real-time processing.

 

But back to virtual instruments. For virtual instruments you want your cores to be as fast as possible first. Then to have more of them. In other words, Xeon chips that have 24 cores at 2.4Ghz is the opposite of what you want. In my experience, you want cores above 4Ghz. Then, as many as you need. For just live play, a quad core is fine. For my main DAW, I'm currently using an Intel 9900K overclocked to 4.8Ghz. Lovely fast cores and plenty of them. But it is the speed that is the best part - that keeps the real-time system happy.

 

This is where laptops, as good as the modern ones are, just run out of steam much earlier than a desktop CPU. The L2/L3 cache sizes are also radically larger, and these help keep the CPU full, and likewise the audio buffers.

 

This also explains why lower buffer sizes strain the system more. If there are only 64 samples in the buffer, the CPU's real-time ability has to keep that full. Obviously, there is twice as much time to do that at 128 samples in the buffer, or four times as much time at 256 samples in the buffer. Higher buffers play more into the way a general purpose CPU works for most non-audio tasks. If your playing latency is acceptable, running larger buffers eases the load on your machine.

 

So, if you are building a machine, look for CPU core speed - the all-core speed. A single "Turbo" core is not useful. The audio needs all the cores to be fast. So, an all core base speed and all-core overclock are what you are looking for. With a 4.8Ghz all-core overclock, I have a very stable platform for audio work, and run plugins and instruments with impunity.