Closed kyr0 closed 4 years ago
The generated wasm for the SOUL code is running within the AudioWorklet callback, so it should be executing as part of the audio thread on the host. I think the stuttering has got worse in recent chrome updates, so it probably indicates a mistake in how this has been implemented, with some garbage collection happening where there should be none. I'll take a look and see if I can work out what's going on.
Ah, I see. Running the code in an AudioWorklet should be fine, even better than doing the processing in a Service Worker. Theoretically, AudioWorklet should be a zero-latency capable thread model. I'm really curious whats going on there. Please let me know if there is anything I can do, like reproducing, executing test code on my machine etc.
Hi Jules',
I just read about SOUL and HEART. Reading the example .soul programs without any prior knowledge of SOUL felt super comfy for me -- I did understood most of the code right away.
I think it's an amazing concept -- also to compile it into a low-level instruction set like HEART and generate WASM. I also played with soul.dev and ran into some stuttering in the sound using the ElectricPiano.soul (TX81Z)... while debugging the code I noticed, that it looks like the performer (I hope I got the terminology right ;) is not running inside of a Service Worker -- and thus maybe not multi-threaded -- yet?
If so... how about letting the WASM run in a service worker and just transfer buffers of audio data forth and back for processing and playback using the service worker / messaging API? I did something like that before... for doing having DSP / analyzing with FFT and everything on live recorded audio in a web app. It did help with the performance a lot. Just saying... :)
Love the whole thing... If there is a way to get involved and help out, let me know.
Best, Aron