Re: AudioWorker/AudioWorklet Status

Hello Andre and Lonce,

Thanks for your opinion. The reason why I asked the obvious question is
that often times people think AudioWorklet will solve all the issues of Web
Audio API. If you have been following the progress in the Chrome's
implementation, we had to cut some corners to bring V8 JS engine and a
dedicated WorkerGlobalScope into the audio rendering thread. It's too early
to tell, but I am keep monitoring for any performance regression.

Once I have the working prototype available behind a flag, I will reach out
to you (and others who are willing to experiment) to collect more feedback.

Regards,
Hongchan


On Tue, Mar 28, 2017 at 4:17 PM lonce <lonce.aggregate@zwhome.org> wrote:

>
> Hi Hongchan and All -
>
>     I just want to be able to write my own processor nodes and for them to
> play nicely with the predefined webaudio nodes (not run on the UI thread).
>
> Best,
>                      - lonce
>
>
>
> On 28/3/17 1:55 pm, Hongchan Choi wrote:
>
> Hello Andre and Lonce,
>
> I believe we completed the spec work. If you find any issue to be dealt
> with before the spec freeze, now is the time:
> https://webaudio.github.io/web-audio-api/#AudioWorklet
>
> Also you can check out the progress in Chrome here:
> https://bugs.chromium.org/p/chromium/issues/detail?id=469639
>
> The progress is certainly not fast because it requires the fundamental
> change in our WebAudio rendering engine. I don't want to break anything to
> bring this new feature, so I am trying to be careful as I can be.
>
> 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?
>
> Regards,
> Hongchan
>
>
>
> On Tue, Mar 28, 2017 at 8:40 AM Raymond Toy <rtoy@google.com> wrote:
>
> 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
>
>
>
>
>
>