They aren't literally doing "GPU acceleration," though. The GPU is a possible target for the language, but not an ideal one. Their prototype is compile-to-WASM,

They aren't literally doing "GPU acceleration," though. The GPU is a possible target for the language, but not an ideal one. Their prototype is compile-to-WASM, which is by itself a good move as a portability concept. A fully audio-focused processing unit, which is what they are really gunning for, would contain a different instruction architecture from either CPU or GPU to reflect the need for a mix of state machine style activity(envelope triggers, voice allocation, etc.) with parallel number crunching for the DSP math. The end result of this would function like existing hardware modules and software plugins: it's assumed to be always running, and the host(sequencer, keyboard, etc.) sends it messages to trigger audio events. The latency you are discussing is messaging and control rate latency, a problem the audio world has considered mostly-solved and production grade(minus a few scaling and edge-case warts) since the invention of MIDI in the 1980's. This would not present more or less control latency than existing options. Audio output would otherwise be desynchronized from the CPU, making the low round-trip latencies described feasible.