Re: AudioWorker/AudioWorklet Status

Hi All,

     First, a hearty 'thank you' to all the architects and engineers 
making audio happen in the browsers. You may not be getting paid for it, 
but it is deeply appreciated impactful.

     I have been biting my tongue on this issue to, but this will be 
such a life changing event for both us developers as well as for the 
general public's audio experience of the web. I know this is a 
distributed collaborative effort, but some kind of overall timeline 
prediction would be really helpful for planning, and just to satisfy 
curiosity!

Many thanks,
                     - lonce
-- 
Lonce Wyse, Associate Professor
Communications and New Media
Director, IDMI Arts and Creativity Lab
National University of Singapore
lonce.org/home <http://lonce.org/home>


On 27/3/17 12:57 pm, André Michelle wrote:
> Hey!
>
>
> What is the current state of the AudioWorklet?
>
> It is very important for us to know when we can use it. The 
> AudioWorklet would improve the experience of our application in many 
> ways. The most obvious is that we expect way less glitches. We know 
> that buffer-underruns can still happen but in very most cases the 
> main-thread was using a little(!) bit more time than we can allow to 
> maintain seamless playback with a reasonable latency.
>
> We already improved it a lot by not(!) using a ScriptProcessor. 
> BufferSourceNodes can be scheduled seamlessly and offer more control 
> and glitch-detection. The audio-rendering is already done inside a 
> worker and sent to the main-thread. But this is where the bad glitches 
> are happening. Small things like layout changes can have an immediate 
> impact on the playback. We also have a version where we use another 
> Browser-TAB to render and playback the audio. This solution works 
> actually best (reduces glitches up to 75% allowing 60fps animations). 
> But this is hardly a solution for long.
>
> Any pointers are welcome.
>
> ~
> André Michelle
> http://www.audiotool.com