GPU Audio v2.3.0 is our biggest step toward making GPU-accelerated DSP feel as predictable as a tightly-tuned native audio path. This release is focused on the things our partners care about most: higher throughput on large graphs across Windows and macOS, lower, more deterministic latency on every supported platform, and a noticeably stronger Metal backend on the Mac. Here's what changed under the hood and why it matters.
The headline engineering effort in v2.3.0 is a brand-new batched GPU scheduling backend that ships on both Windows and macOS. It generates a per-chain blueprint once and then dispatches dependent tasks through a per-block, lock-free batch queue, so the device can pipeline a graph's stages instead of paying per-task launch overhead between every dependency.
On the Mac, these lines up beautifully with Metal's stronger memory-ordering guarantees on Apple Silicon - letting us extract substantially more parallelism out of dependent execution graphs than was previously possible. On Windows, the same backend cuts launch overhead across the board.
The result, measured on our HS-TasNet stem-separation pipeline as a representative large-graph workload:
Bigger graphs benefit the most, because that's where the old per-task launch overhead had the most room to compound. A backwards-compatible legacy path lets previously-built processors run inside the new backend, so existing integrations get the win without a rebuild.
Stability on Metal got a serious pass. We replaced raw `MTL::Library` pointers with smart-pointer ownership (`NS::SharedPtr`), tightened the lifecycle of dispatch objects with deterministic `dispatch_release()`, and corrected several buffer-management paths that - under specific patterns - could lead to crashes during long sessions or heavy plugin reloads.
The net effect: Metal now stays solid under the kind of multi-hour, plugin-heavy sessions our pro users actually run.
Average latency is easy. Latency variance is the hard part - and it's what makes or breaks a real-time audio path. In v2.3.0 we audited the launcher thread and the cross-thread / OS-level hand-offs end-to-end on both Windows and macOS:
The upshot is a flatter latency distribution - fewer spikes, fewer "Where did that 200 µs come from?" moments, and a more predictable RT path for the DAW to trust.
For light or sparse workloads, the most expensive thing in the pipeline is sometimes waking up. When the GPU-communication thread sleeps between launches, the cost of bringing it back - kernel-scheduler wake-up, cache warm-up, page faults - can add up to a noticeable, measurable hitch.
v2.3.0 introduces a configurable launcher keep-alive window (`KeepLauncherActiveMs`, set via `LauncherSpecification.reserved[]`). Within the configured window after the last launch, the launcher thread stays hot in user space - actively waiting on `_mm_pause()` rather than parking on an OS event - so the next launch fires with no thread-wakeup penalty.
It's opt-in and disabled by default, so integrations decide for themselves how to trade a small idle CPU cost against tighter low-latency behavior.
Modern GPUs aggressively drop into low-power states when idle, and they only re-evaluate that decision a handful of times per second. The first launches right after playback starts can land while the GPU is still spun down - so a demanding workload may briefly run at as little as ~1/10 of the available performance, and a DAW can incorrectly conclude it can't run in real-time.
The new GPU heartbeat quietly issues a low-load kernel on a configurable cadence (`HeartbeatKernelTimeMus`, default 1000 µs, auto-tuned via a feedback loop) so the GPU stays in a higher-performance power state even when no audio is being processed. Initial-launch latency stays predictable, and ambitious workloads start cleanly the moment the user hits play.
The heartbeat is opt-in on every platform (off by default), so integrations that don't need it pay nothing, and the ones that do can dial it in for their specific workload.
A handful of smaller, very welcome wins shipped alongside the headline work:
GPU Audio v2.3.0 is faster where it matters (large graphs on both Windows and macOS), steadier where it matters (jitter, light workloads, post-silence start-up), and sturdier under real-world session loads. If you're integrating GPU Audio, update at your earliest convenience - and try the new keep-alive and heartbeat knobs against your most latency-sensitive workloads. We think you'll feel the difference immediately.
Get the current GPU Audio SDK from our GitHub page and contact us if you'd like to know more.
