Re: AudioWorker/AudioWorklet Status

AudioWorklets are in the spec now.  There might be some tweaks as
implementors start implementing it.

I can't speak for any other borwser, but Chrome is actively working on
this.  We don't normally give out timelines for these things, but
everything is done in the open, of course, so you can follow along by
watching crbug.com or crrev.com.

On Mon, Mar 27, 2017 at 2:06 PM, lonce <lonce.aggregate@zwhome.org> wrote:

>
> 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
>
>
>
> 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
>
>
>
>