Intent to Implement and Ship: WebAudio: AudioParam Setter is setValueAtTime
Raymond Toy
Contact emails
rt...@chromium.org,hong...@chromium.org
Spec
http://webaudio.github.io/web-audio-api/
https://webaudio.github.io/web-audio-api/#attributes-5
Summary
When setting the .value attribute of an AudioParam via the value setter, the value is updated exactly as if setValueAtTime(newValue, context.currentTime) were called.
This includes throwing errors that weren't previously thrown and changing the the AudioParam timeline, if any.
Motivation
An AudioParam has a value attribute that can be set directly via the setter or indirectly via a set of scheduled automation events. The interaction between any on-going automation events and the value setter was never specified. This change completely specifies the behavior by making the value setter be exactly equivalent to calling setValueAtTime(newValue, context.currentTime). This is much easier to reason about and will eventually make all browsers interoperable.
Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals
While this has been part of the WebAudio specification for quite some time, we don’t believe any browser has actually implemented this. We do expect this to be implemented.
Compatibility risk
In particular, the following items will change behavior when this is implemented:
Calling the value setter when a setValueCurveAtTime automation is running. This will now signal an error because it is illegal to call setValueAtTime during this automation. The use of setValueCurveAtTime is very low; an http archive search shows just 11 pages out of 16 million using this.
Calling the value setter after a setTargetAtTime. In Chrome, this would make that setTargetAtTime restart with the new value and then approach the target value again. This will now effectively cancel setTargetAtTime and set the value directly.
In other cases, the value setter was basically ignored during other automations. This will now change so that the value will be changed. Because a setValueAtTime event is inserted into the timeline, the currently running automation will be changed, and the next event will start using this new setValueAtTime event.
We believe the simultaneous use of the setter and automation is rare. Searching the http archives will be ineffective because it’s very hard to know if there is any simultaneous usages. The most effective test is to run the actual application and listen for differences.
To mitigate the effect of this change, we propose adding a deprecation message that the behavior of the value setter will change. The proposed target date is M65.
Ongoing technical constraints
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? Yes
OWP launch tracking bug
http://crbug.com/764396
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/6254081119092736
Requesting approval to ship?
Yes, after the deprecation period is up.
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXH7wjKp_-VeCQrcJRv-KkbR%3DQgaQsyi18UifFTFkiuz7A%40mail.gmail.com.
Dimitri Glazkov
LGTM1 to ship in M65 with a deprecation warning in M64.On Mon, Oct 9, 2017 at 2:29 PM, Raymond Toy <rt...@chromium.org> wrote:
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/CAE3TgXH7wjKp_-VeCQrcJRv-KkbR%3DQgaQsyi18UifFTFkiuz7A%40mail.gmail.com.
--
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/CAOMQ%2Bw8onx_vGFR9FG53Sz7d6uQAV3Vkd01mg-%2BhoY7Zy4pO4A%40mail.gmail.com.
Raymond Toy
LGTM2
On Mon, Oct 9, 2017 at 7:13 PM Chris Harrelson <chri...@chromium.org> wrote:
LGTM1 to ship in M65 with a deprecation warning in M64.On Mon, Oct 9, 2017 at 2:29 PM, Raymond Toy <rt...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXH7wjKp_-VeCQrcJRv-KkbR%3DQgaQsyi18UifFTFkiuz7A%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXHbhmoCKemc3CUAm%3Dx7Ej9nx-dJ1kBhWtPuCU2b_1Jw0w%40mail.gmail.com.
Raymond Toy
LGTM3Do you have any way to estimate what fraction of calls will have their behavior changed? Generally deprecation messages are reserved for "this behavior will stop working on this date". We don't generally do warnings like "the API you called might behave differently" (we've had too much problem with warning spam/blindness in the past - warnings should all be actionable). It might be reasonable to do a verbose-level (off-by-default) warning for something like that. Or if you can target a specific set of cases that used to be valid which are now invalid, generating a warning for those is fine.