4 ms·

How can a language itself be low latency? "Less CPU" than what? The whole page is full of nothing but nonsensical hype, I was half expecting it to say "blockcha

How can a language itself be low latency? "Less CPU" than what? The whole page is full of nothing but nonsensical hype, I was half expecting it to say "blockchain" shortly after "paradigm shift". Also, if it's GPU based (shaders?), that's going to increase latency not decrease it, as anyone who understands bus transfers and that GPUs are optimised for throughput not latency will know.

deleted 8y ago
[deleted]
charlesism 8y ago
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.
IshKebab 8y ago
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).
julesrms 8y ago
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.

deleted 8y ago

[deleted]

charlesism 8y ago

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.

IshKebab 8y ago

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

julesrms 8y ago

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.