Audiogridder can run real time (with little benefit on the same machine, if any) or as low as 10ms, or maybe even lower, as reported by the DAW - which is less than many plugins. Of course it'll depend on the system and plugins as to how low you can go.Ploki wrote: Mon Aug 04, 2025 8:31 am(You did, crossforum).vitocorleone123 wrote: Mon Aug 04, 2025 12:43 amI wasn’t replying to you here, but thanks for jumping in.Ploki wrote: Sun Aug 03, 2025 8:52 amBruh you’re twisting what i wrotevitocorleone123 wrote: Sun Aug 03, 2025 3:27 amIt’s clearly designed to sell to Apple users more. They coded it as a single thread rather than adding some latency and designing it for multithreaded CPUs (which, then, could penalize Apple users).Funkybot's Evil Twin wrote: Sun Aug 03, 2025 1:25 am The Windows CPU usage in the current state makes it impractical. So get that. But the sound is something else. Let's see how these optimizations go.
Multithreading doesnt magically reduce CPU usage and is not as simple as “more latency” - more complex scheduler means more overhead.
U-He synths on M chips smoke many intel offerings and u-he synths were coded before M chips were out
They’re not favoring M chips, apple just made better chips for the job.
I was trying to explain to you why making an audio process multi threaded isn’t as simple as “make multithreaded” and that it adds complexity and latency, and now you’re twisting the reality of what i said. I didn’t say that it would reduce CPU usage, if anything it adds overhead.
This wasn’t designed to sell more to apple users, ever since M chips came out people have been touting how good they are for audio processing.
All in all, multithreaded design would very likely make CPU performance WORSE.
With your expertise, can you explain how Audiogridder makes it so that the same compressor (Relab 176) can have a lot more instances running - more than just increasing the ASIO buffer, and seems to be having the load spread across cores on the same machine? Genuine question.
Have you tested with audiogridder?
I haven’t seen any meaningful post about it, just that it reduces DAWs cpu meter (duh).
I have limited knowledge of audio gridder, but if it adds enough latency (supposedly it adds about 130ms by default) it can effectively work as “offline” processing with small intermittent droputs if it gets enough time within that 130ms to reconstruct the signal. The processing is done outside the DAW and can do thread scheduling differently and can split audio into chunks. I bet my ass it works at higher buffers than 128/256 of your DAW, hence the huge latency.
That isn’t feasible for a playback audio engine because it runs on DAWs processing clock. (Think of it as realtime vs offline bounce).
This is speculation.
Would have to try it tho but i doubt i’ll get meaningful results on an M1.
The jist of why it works better on M vs intel:
- Memory latency (many people think apple’s practice of soldering RAM is greed / it is, but it also reduces memory latency by a lot)
- L2/L3 cache (M chips have a lot)
If looking cross-forum, yes, I posted on GS about how big of a difference it made. Within S1, if I load 2 stereo instances on one track (48khz 32 buffer), it starts hitting red on the DAW CPU meter. If I use Audiogridder plugin/server on the same computer, I can use 16+ tracks with 2 stereo instances each track before it starts hitting red. I just don't want to have to use Audiogridder so I tend to avoid plugins that aren't coded well/optimized well, especially fx plugins. Audiogridder distributes the load across cores, and can do so quickly and efficiently, but it does take a few ms to do it.
Given that Relab provides a 4x OS option (default off), I don't see why having a multi-core option that adds a little latency (default off) would hurt - other plugins incur latency when enabling oversampling, for example. It just takes time and effort to code. It's clear that the path of least resistance for the business was to not code such a thing, so they made choices accordingly.
On the plus side, the next Ryzen chips are supposedly hitting 6+ ghz with double the current cores and have up to 128mb L3 cache. One can hope it's faster. I plan to get one and swap it out with my current CPU.

