> As a contributor to the spec/implementation of AudioWorklet, I would like to ask a question to you - what kind of technical difficulty do you have due to the lack of AudioWorklet? We tried a lot of workarounds to master the actual problem: "All ‘custom generated’ audio must pass the main-thread." We figured that the actual number crunching is not a problem at all. Our current version is in Flash. Javascript is already faster in code execution. But in order to have low latency we need to send the computed audio as fast as possible to the sound-card. The problem is that low latency requires a higher update rate than the 16ms (60fps) in the main-thread. Timers get weak when the UI is under load. We can compute audio fast enough to cover low latency but we currently need to send it to the main-thread in order to be played back. The scriptprocessor adds latency without taking the load of the main-thread into account (which the flashplayer did quite good). We already worked with the BufferSourceNode to schedule our audio-blocks. That is much better. But if the main-thread needs a little bit more time for layout or complex format changes, it will block the audio flow and creates glitches. So the main thing we are looking for is to write an audio-stream from a worker to the sound-card without the detour over the main-thread. We know that the AudioWorklet might do much more, but that is the main issue for us right now. ~ André Michelle http://www.audiotool.com <http://www.audiotool.com/>
Received on Tuesday, 28 March 2017 21:23:13 UTC