4 ms·
This is a really great writeup -- it's concise and to the point, the demos are good. It's not just audio; timing in general is kind of terrible in Javascript.
by danShumway 7y ago
This is a really great writeup -- it's concise and to the point, the demos are good.
It's not just audio; timing in general is kind of terrible in Javascript. Spectre/Meltdown made it worse, because now some browsers introduce arbitrary jitter for security purposes. The advice I've always seen is to try and avoid ever doing your own timing in Javascript -- use `requestAnimationFrame` instead of `setTimeout`, use web audio scheduling instead of `setTimeout`. Basically, avoid `setTimeout` for most high-precision things if possible.
I don't know what the status is with shared array buffers and WASM. At one point I was very excited about the potential of WASM to get around some of the problems above, but last I checked, this was being partially held back by the same security concerns.
- the_gipsy 7y agoI don't think it was concise. It could be shortened to "timers in js are extremely imprecise and not useful for real-time audio. use the audio API, which has real-time scheduling for audio." and then maybe go deeper and show examples of that.
- jbob2000 7y agoI guess my next question then is... what are you doing in javascript that you need this level of precision? If you need this level of precision, there are so many other things that are going to mess with you, other than timing problems.
- tabtab 7y agoThe desktop has spoiled everybody. Everybody wants web apps to act like and have the control of desktop apps. So far, it's not possible without top IT rocket scientists, and the next browser release will probably break the rocket anyhow.