3 ms·

"The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described." Yup. That is being worked on b

"The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described." Yup. That is being worked on by W3C and the WebAudio committee as we speak. WebWorker based JS processing is something being considered. https://github.com/WebAudio/web-audio-api/issues/113 https://github.com/WebAudio/web-audio-api/issues/113 http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0073.html http://lists.w3.org/Archives/Public/public-audio/2013OctDec/... I am expecting this to be resolved in a few months. (hopefylly?) If the threading issues are resolved, then real time audio rendering doesn't take that much processing power and can be easily done in JS. Infact if there is nothing else contending for the EventLoop (like in this example of WavPot) the ScriptProcessorNode is able to meet the real-time guarantees pretty well, while still doing decent processing. Also going forward, with Technologies like SIMD.js and asm.js more can be done within a single onprocess callback.

chrisdevereux 12y ago
Meeting real-time guarantees pretty well isn't good enough for a DAW. Not without a lot of buffering (and therefore latency), anyway. The WebWorker proposal is interesting. If the worker has its own heap and realtime scheduling with a correctly configured GC, it would be a big improvement. Getting the different implementations to work consistently enough will be challenging, though. Meeting realtime deadlines is difficult enough when working in C with a known OS and audio stack.
- chrislo 12y ago
  We're working on a test suite for implementations, which will hopefully help with some of the basics, but it will be challenging to get full coverage. https://github.com/w3c/web-platform-tests/tree/master/webaudio https://github.com/w3c/web-platform-tests/tree/master/webaud...

chrisdevereux 12y ago

Meeting real-time guarantees pretty well isn't good enough for a DAW. Not without a lot of buffering (and therefore latency), anyway. The WebWorker proposal is interesting. If the worker has its own heap and realtime scheduling with a correctly configured GC, it would be a big improvement. Getting the different implementations to work consistently enough will be challenging, though. Meeting realtime deadlines is difficult enough when working in C with a known OS and audio stack.

chrislo 12y ago
We're working on a test suite for implementations, which will hopefully help with some of the basics, but it will be challenging to get full coverage. https://github.com/w3c/web-platform-tests/tree/master/webaudio https://github.com/w3c/web-platform-tests/tree/master/webaud...