7 ms·

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 execut

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).

pixelpoet 8y ago
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.
- charlesism 8y ago
  I was hoping you wouldn't read that. I hit delete as soon as I realized I was being rude. Sorry about that.
  - pixelpoet 8y ago
    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.
- jungler 8y ago
  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.

pixelpoet 8y ago

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.

charlesism 8y ago
I was hoping you wouldn't read that. I hit delete as soon as I realized I was being rude. Sorry about that.
- pixelpoet 8y ago
  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.
jungler 8y ago
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.