4 ms·

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes great care to deliver that; it's a JavaScript "frontend" API but all of the actual handling of audio is done natively with high quality realtime constraints. The core engine is all native C/C++, and we run in the web by compiling to wasm and running inside a web worker. For delivering a desktop app or audio plugin, the native engine is compiled directly into the target binary. So, while JavaScript and garbage collectors can bring a performance concern, we're only using JavaScript there for handling the lightweight virtual representation of the underlying engine state, and for that role JavaScript is plenty fast enough and the garbage collector quite helpful!

danuker 4y ago
> by compiling to wasm TIL WASM bypasses JS completely, including its memory management.
Flankk 4y ago
That's great on paper but how do I actually use it? If I want to play back a wavetable you have el.table() but it's missing the oversampling and decimation tools required for antialiasing. The el.lowpass() is a biquad which is not suited well for modulation. How can this compete with JUCE when the documentation and features are so sparse?
iainctduncan 4y ago
Ah cool, after I posted I was wondering if this was the case. I was just thinking "maybe the renderer is in WASM"? That's pretty cool, it will be interesting to watch. I do something very vaguely similar in my computer music work where Scheme orchestrates C level objects. Personally, I wouldn't want to use JS as the high level orchestrator myself as it's such a dog's breakfast of a language, but I can see that many might.
- FractalHQ 4y ago
  > such a dog's breakfast of a language That’s why we have supersets like Typescript and Svelte!
iainctduncan 4y ago
You should really fix the initial impressions you make from the site to get that front and centre though. Experienced audio devs are going to dismiss this unless you make it clear very quickly.
- trypwire 4y ago
  100%. I'm actively learning exactly this, haha :). It's helpful feedback, thank you!
bricklebrack 4y ago
This is my new favorite comment for illustrating the perilous future of general computing and how it needs to be taken away from JavaScript if we have any chance of survival. Electron, Webassembly fetishism, the pursuit of language synchrony at the expense of common sense, it all gets you this. This comment. Right here. This is the future of software and it should scare the shit out of you. Let me get this straight: you realized latency was a concern, so you wrote in C/C++ (which, exactly?), then turned it into wasm so you can run it in a Web worker? What the hell was the point of that? That’s like saying you bought an M6 and converted it to a foot-powered bicycle. What exactly do you think wasm does? You seem to be implying that you think the native engineering you invested in continues to matter, in the same way, after you do that. You also imply heavily that you understand the wasm you’re executing to still be native. Do you think that? Do you understand what you’re giving up in the Web worker? As in, directly tied to latency and real-time requirements, your whole reason to go native in the first place? Whatever your response is, deep down, you and I both know it’ll be justification to do Web things for Web’s sake. I know this because everyone I’ve had this discussion with has played the same notes (imagine the deployment model!) while failing to understand that they’re justifying their preference. The only people who build Web stuff want to build Web stuff. In the high performance sphere, of which DSP is a very mature practice, this looseness with the fundamentals of software is going to put you out of the game before you’re even started.
- deleted 4y ago
  [deleted]
- moron4hire 4y ago
  Do you understand how WASM and Web workers work? Do you understand that low-enough-latency audio doesn't take a super computer anymore? Yeah, if you were working on DSP stuff in the 1990s, you were a hot shit programmer. Nowadays, it doesn't really say much at all. And it certainly doesn't justify talking about it as if it were a moral failure to not treat DSP with respect.
  - PaulDavisThe1st 4y ago
    > Do you understand that low-enough-latency audio doesn't take a super computer anymore It never did. Low latency audio has almost nothing to do with CPU power. Here's a summary of some of the issues faced on modern general purpose computers: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ https://manual.ardour.org/setting-up-your-system/the-right-c... I know how WASM and Web workers work. Since nothing you can do in WASM or a web worker has anything to do with either (a) realtime scheduling priority (b) actual audio hardware i/o, they don't have much to do with solving the hard parts of this. Browsers in general do not solve it: they rely on relatively large amounts of buffering between them and the platform audio API. Actual music creation/pro-audio software requires (sometimes, not always) much lower latencies than you can get routing audio out of a browser.

danuker 4y ago

> by compiling to wasm TIL WASM bypasses JS completely, including its memory management.

Flankk 4y ago

That's great on paper but how do I actually use it? If I want to play back a wavetable you have el.table() but it's missing the oversampling and decimation tools required for antialiasing. The el.lowpass() is a biquad which is not suited well for modulation. How can this compete with JUCE when the documentation and features are so sparse?

iainctduncan 4y ago

Ah cool, after I posted I was wondering if this was the case. I was just thinking "maybe the renderer is in WASM"? That's pretty cool, it will be interesting to watch. I do something very vaguely similar in my computer music work where Scheme orchestrates C level objects. Personally, I wouldn't want to use JS as the high level orchestrator myself as it's such a dog's breakfast of a language, but I can see that many might.

FractalHQ 4y ago
> such a dog's breakfast of a language That’s why we have supersets like Typescript and Svelte!

iainctduncan 4y ago

You should really fix the initial impressions you make from the site to get that front and centre though. Experienced audio devs are going to dismiss this unless you make it clear very quickly.

trypwire 4y ago
100%. I'm actively learning exactly this, haha :). It's helpful feedback, thank you!

bricklebrack 4y ago

This is my new favorite comment for illustrating the perilous future of general computing and how it needs to be taken away from JavaScript if we have any chance of survival. Electron, Webassembly fetishism, the pursuit of language synchrony at the expense of common sense, it all gets you this. This comment. Right here. This is the future of software and it should scare the shit out of you. Let me get this straight: you realized latency was a concern, so you wrote in C/C++ (which, exactly?), then turned it into wasm so you can run it in a Web worker? What the hell was the point of that? That’s like saying you bought an M6 and converted it to a foot-powered bicycle. What exactly do you think wasm does? You seem to be implying that you think the native engineering you invested in continues to matter, in the same way, after you do that. You also imply heavily that you understand the wasm you’re executing to still be native. Do you think that? Do you understand what you’re giving up in the Web worker? As in, directly tied to latency and real-time requirements, your whole reason to go native in the first place? Whatever your response is, deep down, you and I both know it’ll be justification to do Web things for Web’s sake. I know this because everyone I’ve had this discussion with has played the same notes (imagine the deployment model!) while failing to understand that they’re justifying their preference. The only people who build Web stuff want to build Web stuff. In the high performance sphere, of which DSP is a very mature practice, this looseness with the fundamentals of software is going to put you out of the game before you’re even started.

deleted 4y ago
[deleted]
moron4hire 4y ago
Do you understand how WASM and Web workers work? Do you understand that low-enough-latency audio doesn't take a super computer anymore? Yeah, if you were working on DSP stuff in the 1990s, you were a hot shit programmer. Nowadays, it doesn't really say much at all. And it certainly doesn't justify talking about it as if it were a moral failure to not treat DSP with respect.
- PaulDavisThe1st 4y ago
  > Do you understand that low-enough-latency audio doesn't take a super computer anymore It never did. Low latency audio has almost nothing to do with CPU power. Here's a summary of some of the issues faced on modern general purpose computers: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ https://manual.ardour.org/setting-up-your-system/the-right-c... I know how WASM and Web workers work. Since nothing you can do in WASM or a web worker has anything to do with either (a) realtime scheduling priority (b) actual audio hardware i/o, they don't have much to do with solving the hard parts of this. Browsers in general do not solve it: they rely on relatively large amounts of buffering between them and the platform audio API. Actual music creation/pro-audio software requires (sometimes, not always) much lower latencies than you can get routing audio out of a browser.