3 ms·

very very cool. the visual aspect is very impressing. I also use Svelte for this browser-based music live coding environment I am developing: https://glicol.o

very very cool. the visual aspect is very impressing. I also use Svelte for this browser-based music live coding environment I am developing: https://glicol.org https://glicol.org The issue with raw Web Audio API is that when there are some heavy stuff on the main thread (in your case the visual feedback), the audio may get glitches. WASM + AudioWorklet is SOTA the solution for this, and Glicol 's tech stack is Rust->WASM->AudioWorklet + SharedArrayBuffer. I also porting the audio engine of Glicol as an NPM package: https://glicol.js.org https://glicol.js.org So if you wish some better audio performance for future development, perhaps you can take a look on that. It provides better audio performance and friendly APIs. I would be happy to update the audio lib based on your feedback.

fenomas 4y ago
> when there are some heavy stuff on the main thread the audio may get glitches Where have you seen that? TFA is just using oscillators, not ScriptProcessor or anything, so one would expect all the heavy audio work to be happening outside the main thread. Personally I use webaudio to do dynamic music for a game, and even though the game is reasonably heavy (3D, physics, etc) I've not noticed any particular glitching.
- chaosprint 4y ago
  You are right! I should say ScriptProcessor there. But for heavy use of audio, especially when there are lots of interactions (often you want your own abstraction rather than the built-in nodes) and sample-level time should be taken into account, WASM+AudioWorklet should definitely be the first choice: https://youtu.be/GfC2WTStW8M?t=1084 https://youtu.be/GfC2WTStW8M?t=1084