Questions & Answers

Use More Optimal Cores or Configuration for Low Latency / Green Z Monitoring (Virtual instruments)

+62 votes
asked Jan 20, 2020 in Recording by robertgray3 (42,190 points)
edited Jan 30, 2020 by robertgray3
Note: I’m on macOS. Dual OS users tell me that the performance is much worse on macOS than Windows so maybe this request is limited to macOS.

Please allow Low Latency / Green Z Monitoring for virtual instruments to in some way utilize my less busy cores instead of just the first core. Perhaps some of the processing could be spread out, perhaps all of it, honestly I’m not really sure because I’m just an end user. Maybe the duplicate instance that takes GUI input could reside somewhere else?

Currently, the system is designed to place 2 instances of the instrument and some additional overhead on the core with the audio driver, which is always the first core and one of the busiest cores in the OS.

I have a Presonus Quantum 2 on thunderbolt and an 8-core 3.0 GHz system. With heavy VSTis putting all this extra load on the 1st core can cause dropouts, crackles, crackling, cackling, cackles etc (choose your noun) even on a CPU with a very high single-core clock speed, simply because so much is already on that core.

When I disable Green Z and turn the buffer down very low I can play the VSTis better (not sure whether it’s because they're not placed on suboptimal cores or there’s just less overhead to manage) but this negates all the benefits of the Dropout Protection system.

I think more efficiency here would help even considering clock speeds increase year after year. I’ve noticed since my first 1.8 GHz multi-core system thst every new plugin and program and OS just uses more resources, so the first core is still crowded with 3.0 Ghz

1 Answer

+1 vote
answered Jan 23, 2020 by robertgray3 (42,190 points)
edited Jan 23, 2020 by robertgray3
Side note: my current CPU is 3.0 GHz. The top single core clock speed on a new Mac Pro is 3.5 GHz.

I know the CPU and OS play a part but I’m a little skeptical that another 500 MHz and $6000 would solve this first-core-load issue.