Intent to continue experimenting: AudioWorklet

64 views
Skip to first unread message

Hongchan Choi

unread,
Mar 1, 2018, 1:33:40 PM3/1/18
to blink-dev

Contact emails

hong...@chromium.org, rt...@chromium.org


Spec

https://webaudio.github.io/web-audio-api/#AudioWorklet


Summary

Since the Origin Trial started at M64, we received positive feedbacks from the participants (tracking issue). Based on the input and API Owners' approval, we are shipping the AudioWorklet by default in M66.


Related Blink intents

Intent to implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/fBfWECEGZa8/Jr_3UDsCAQAJ

Intent to experiment:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/oeBf3websgM/Smi7gQxjAQAJ

Intent to ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/dEsseBBMbs4/rvdT2wK4BQAJ


Goals for continuing experimentation

The current experiment expires on March 6 and the first stable release of AudioWorklet will be around April 24. There is a gap between these two dates and we want to support the participants so they can keep their page running.


Developer feedback from previous OT

As of February 2018, ~25 participants from different areas (e.g. pro-audio and game) registered for the Origin Trial. We collected feedback from participants through the tracking issue. Audio glitches due to the GC in the rendering thread were reported from the initial release, but we profiled and analyzed to pinpoint the problem and addressed it by using the V8 API in the rendering thread. Since the optimization patch, the rendering performance is satisfactory for the most participants.


Experimental Timeline

Currently enabled up to Mar 6th, 2018: Chrome 65 Stable

Enabled: March 6th, 2018: Chrome 65 Stable

Disabled: April 24th, 2018: Chrome 66 Stable


Ongoing technical constraints

None.


Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.


OWP launch tracking bug

https://crbug.com/469639


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4588498229133312


pad...@mozilla.com

unread,
Mar 2, 2018, 5:37:35 AM3/2/18
to blink-dev
Hi,

I'd like to make a note here that rather serious spec issues, with possible breaking API changes have surfaced very recently:

The first one in particular is critical to solve to be able to implement this feature in multiples UA in a way that it is interoperable.

Chrome experiments are certainly one of the reasons some of those issues got found in the first place, so continuing to experiment sounds perfect.

However, being quite unfamiliar with the release process of Chrome, and uncertain of the speed at which we can solve those issues in the spec (again, in particular the first one),I don't know what to think about the timeline for release proposed here.

Thoughts?

Thanks,
Paul.

Hongchan Choi

unread,
Mar 2, 2018, 10:08:43 AM3/2/18
to pad...@mozilla.com, blink-dev
Hi Paul,

Thanks for jumping into the discussion here, bringing those issues.

I believe the issue 1511 is really about writing the text, and I don't think the actual implementation can be incompatible because of the missing text. I posted my response on the issue there but let me give you some more details; AudioWorkletGlobalScope has a task scheduler drives an event loop and all the tasks scheduled to the scope will be queued and executed in that order. The comment from Anne resonates with the current implementation with Chrome.

> Chrome experiments are certainly one of the reasons some of those issues got found in the first place, so continuing to experiment sounds perfect. 

Have you found actual incompatibility between FireFox and Chrome? Can you share any example that highlights such incompatibility?

For the issue 1491, this is a cosmetic spec issue and we have a PR under the review. Is there anything more to resolve? I thought we agreed on this.

Also the changes in the issue 1480 and 1464 are not affect the actual IDL. Please note that the AudioWorkletProcessor.process() method is a callback from the WebAudio render system and it does not have a formal IDL. These optimizations won't involve the future IDL change, it is more of adding useful hints as a additional callback function argument.

> uncertain of the speed at which we can solve those issues in the spec (again, in particular the first one)

All in all, I think we can clarify few bits in our processing model in the spec with the event loop and the rest of the issues feels cosmetic to me. As you already know, we made a decision on shipping AudioWorklet by default in M66 and I don't think the first issue is serious enough to revert the decision.

Thanks,
Hongchan


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f12a3c16-4759-4e45-8e5c-1265851a6477%40chromium.org.

Raymond Toy

unread,
Mar 2, 2018, 1:35:35 PM3/2/18
to Paul Adenot, blink-dev
On Fri, Mar 2, 2018 at 2:37 AM, <pad...@mozilla.com> wrote:

The last three are not serious spec issues.  1480 and 1464 are possibly nice optimizations that can be done by the browser so the developer doesn't have do the himself, saving a small amount of CPU, because the browser probably has the information already.  But as an optimization, browsers aren't being required to provide the hints.

1491 is a small optimization to make it slightly easier for the developer to get precise timing.  Without this, the developer can still derive the frame precisely from the current time by computing currentTime * sampleRate and rounding that to the nearest multiple of 128. (Because the frame count and hence time advances 128 frames at a time.)

The first one in particular is critical to solve to be able to implement this feature in multiples UA in a way that it is interoperable.

I think this is the only one that is a serious spec issue.  But it affects all processing and isn't really tied to AudioWorklets in particular. Something we need to fix in the working group.


Chrome experiments are certainly one of the reasons some of those issues got found in the first place, so continuing to experiment sounds perfect.
 
Certainly having an experiment made it easier to find these things. In particular, I filed the last three issues without having implemented any AudioWorklet. I failed to use my knowledge of Chrome in reviewing the AudioWorklet design for these small issues.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Hongchan Choi

unread,
Mar 5, 2018, 11:29:47 AM3/5/18
to blink-dev, Paul Adenot, Raymond Toy
Thanks for the clarification, Raymond!

As Raymond responded, these 4 issues do not have anything to do with continuing experiments. Particularly, the issue 1511 is about making a small tweak in the processing model for the entire Web Audio API, and AudioWorklet should fall into the places when the revision is made. The other 3 issues are cosmetic or optional.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Jason Chase

unread,
Mar 5, 2018, 1:08:16 PM3/5/18
to Hongchan Choi, blink-dev, Paul Adenot, Raymond Toy
I'm commenting from the context of the overall origin trials program. The general intent is not to have features be continuously available from origin trial through to shipping to stable. 

The origin trial policy is to have a minimum 1 week break in feature availability (see this doc). A primary motivation is to encourage feature authors to actually make breaking changes, as needed, between trial and shipping.

Regardless of the severity of the spec issues raised, I don't think a trial extension should proceed without a break in availability. It's reasonable to minimize developer impact by having only the 1 week break, but there should be a break.

Thanks,
Jason

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFJ7ZjFUAfR2t_jS3AP%2Bju7Kg-foMq2ge9XdFUtOww1fg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Hongchan Choi

unread,
Mar 5, 2018, 1:28:47 PM3/5/18
to Jason Chase, blink-dev, Raymond Toy
Thanks Jason for the input! I did not know about the mandatory break. Then I would like to change the expiration date of proposed experiment to April 17.

Would it be okay?


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFJ7ZjFUAfR2t_jS3AP%2Bju7Kg-foMq2ge9XdFUtOww1fg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Rick Byers

unread,
Mar 5, 2018, 9:04:15 PM3/5/18
to Hongchan Choi, Jason Chase, blink-dev, Raymond Toy
Extending the trial to April 17 to have the mandatory 1-week break between experimentation and shipping LGTM.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFJ7ZjFUAfR2t_jS3AP%2Bju7Kg-foMq2ge9XdFUtOww1fg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNvxWv%3DB0aWU0opv12EskN5v5qiLs040hH42A1Ad%3DYPexA%40mail.gmail.com.

Reply all
Reply to author
Forward
0 new messages