Intent to Implement and Ship: WebAudio: Selectable automation rate for AudioParam
Raymond Toy
Contact emails
rt...@chromium.org, hong...@chromium.org
Explainer
No explainer
Design doc/Spec
https://webaudio.github.io/web-audio-api/
In particular: https://webaudio.github.io/web-audio-api/#enumdef-automationrate and https://webaudio.github.io/web-audio-api/#dom-audioparam-automationrate
Summary
Allow the user to select the automation rate (“a-rate” or “k-rate”) for an AudioParam.
Motivation
Some time ago the automation rate for BiquadFilterNode’s were changed from “k-rate” to “a-rate” to support some use cases where “k-rate” had strange audio effects. This change greatly increased the complexity of the filter because the filter coefficients had to be computed every sample instead of once per 128-sample rendering block. We knew this added complexity at the time, but didn’t fully understand all the consequences especially since dezippering was also recently removed from chrome. The recommended solution was to use `setTargetAtTime()` as the replacement, but this causes the coefficients to be computed each sample, which is very complex. This was reported by developers recently, and also reported as a spec issue/feature request a while ago.
To fix this, allow the developer to choose the desired automation rate for each AudioParam. Some parameters are fixed to be “k-rate” when it does not make sense for an “a-rate”. These cases are enumerated in automation rate constraints.
Risks
Interoperability and Compatibility
There is some interoperability risk. As far as we know, only Chrome has implemented a-rate BiquadFilters so the complexity issue has only affected Chrome. But this is a required part of the spec so we fully expect all browsers to implement a-rate support. At that point, those browsers will also have the same complexity issue, so allowing selectable automation rate will be important for them as well. Firefox was involved in all the discussions and agreed that this is an important issue to resolve.
Edge: No signals
Firefox: No signals, but was involved in the spec discussions and did not oppose
Safari: No signals
Web developers: Positive: https://github.com/WebAudio/web-audio-api/issues/1269#issuecomment-371814961
Ergonomics
Are there any other platform APIs this feature will frequently be used in tandem with?
No.
Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
This should actually help performance for the common case where a-rate automation is not needed.
Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is?
No.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
It cannot be polyfilled. It’s relatively easy to use, but additional documentation would be helpful especially to explain when to choose k-rate over a-rate.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
No, not yet, but we will add tests during implementation since this is a new addition to the API.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5164143287992320
Requesting approval to ship?
Yes
Chris Harrelson
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXEqNA89nh-EcQGTNTTPNxob0_%2Bk8tqguxSHOeub5wOMxg%40mail.gmail.com.
Jochen Eisinger
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-MU6La4H8eruT8yjshh30jvXW3wGyObsz8cHfREZugTw%40mail.gmail.com.