It's not the language itself that makes it low latency. It's the fact that it is effectively an audio shader language. Think GLSL but for audio. In the same way that GLSL can lead to lower latency graphics, this can lead to lower latency audio by sending the actual code to be executed at a place that it closer to the output.

For example it can be executed in the kernel driver, in a DSP, or even on an external device (e.g. a wifi speaker).

Apologies for having allowed our more marketing-oriented folk do the website content - we're still writing some developer-appropriate less hypey docs which we'll release soon.

The concept is hard to explain in a couple of sentences - the keynote is really the best place to go right now if you want to properly understand what we're trying to do - but essentially, it's about using less CPU than the way we currently run audio code (i.e. running on a CPU in a non-realtime OS, in user-space)

And no, GPUs were never part of the plan for this. I've never considered GPUs to be a remotely sensible place to run audio code. We're mainly talking about DSPs or CPUs with realtime OSes.

...however, surprisingly, after we announced it, we had several very serious companies ask us whether SOUL could run on a GPU because they do have use-cases where that kind of architecture fits quite nicely. Wouldn't have expected that, but it may be something we look into if people want it.

I think he mentioned GPU just as an example of acceleration via dedicated hardware. In the keynote, one of his example use-cases was sending SOUL code to execute on a set of digital studio monitors (ie: speakers with their own sound card).

I like how you deleted your "did you even watch the video" comment before replacing it with this one, effectively turning the question back on yourself :)

With that in mind, did you read my comment? I explicitly mentioned how GPU "acceleration" is going to increase latency, which contradicts one of the very few definite statements they make.

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.

I was hoping you wouldn't read that. I hit delete as soon as I realized I was being rude. Sorry about that.

It was much more ironic than it was rude, because yes I was referring to the video, as you would surely know because you also watched it... right?

Anyway, I can understand the supposition that GPUs are good for audio processing because they have oodles of processing power and memory bandwidth, however this will hurt latency because there's at least one extra bus hop (assuming the GPU can DMA to the sound card, which I doubt, and if not it's two extra hops!) and it's not like modern multicore CPUs lack throughput for audio purposes.

tl;dr They claim some latency advantage and then use GPU acceleration as an example; as someone doing lots of GPU coding I find that contradictory because of the extra bus transfers.