3 ms·
I mean you can do trivial little toys in the browser sure, but low-latency, real-time audio rendering can't be done in a garbage collected environment (unless t
by hctaw 6y ago
I mean you can do trivial little toys in the browser sure, but low-latency, real-time audio rendering can't be done in a garbage collected environment (unless the GC is running concurrently and guaranteed not to stall the audio rendering thread). Which the browser does not provide you.
You can get away with it because the complexity is low. When you begin dealing with higher complexities (like even a modest amount of polyphony in a decent synthesizer) you will push up against the limits of what the browser is capable of. That's what I'm trying to say. There are products like bandlab that do incredibly things in the browser, but their competitors do far more with less just by leaving it.
As for higher level APIs... sure you can do it. There are things like WebAudio, Supercollider, Max/MSP, Pure Data, the new SOUL language posted recently, etc. But ultimately what every app needs is an API where they pick which samples to fill a buffer with (what you're calling "sound waves to the sound driver" I think). Mostly because the high level APIs sound bad and you will eventually need non-naive DSP.
Look - everyone knows low level APIs and languages kinda suck to program against. But it's not for lack of trying that serious audio software isn't running in the browser or in managed languages.
- deleted 6y ago[deleted]
- fenomas 6y ago> Which the browser does not provide you. WebAudio does indeed provide it. The audio data doesn't live in the JS VM, and isn't GC'ed like regular JS.