Intent to Ship: WebAudio: Remove Dezippering

[Raymond Toy]

Contact emails

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

Spec

http://webaudio.github.io/web-audio-api/

https://github.com/WebAudio/web-audio-api/issues/76

Summary

There are no API changes to WebAudio, but dezippering was removed from the spec in Sep 2015, and we need to remove this from our implementation.

Motivation

WebAudio originally shipped with dezippering support.  When an AudioParam value was set directly with the value setter, the value was not updated immediately.  Instead, an exponential smoother was applied with a time constant of about 10 ms so that the change was done smoothly, limiting any glitches.  It was never very well-specified which parameters had smoothing and what the time constant was.  It wasn’t even obvious if the actual time constant was the appropriate value.

After much discussion, the working group decided to remove dezippering completely from the spec. Now, the value is changed immediately when set. In place of dezippering, it is recommended that developers use the existing AudioParam setTargetAtTime() method to do the dezippering. This is equivalent to the old dezippering, but gives the developer full control on when to apply it, and on how fast to change, and on exactly which parameters should be smoothed.

Removing this reduces developer confusion on what AudioParams have dezippering. This also simplifies the internal implementation in Chrome.

Interoperability and Compatibility Risk

This is potentially a very user-visible change.  For example, if the gain of a GainNode is set, the change will become instantaneous, possibly causing a glitch in the audio.  This didn’t happen before because dezippering was used in the gain value of a GainNode.  Other nodes that have dezippering: DelayNode, StereoPannerNode, BiquadFilterNode, and OscillatorNode,  (Dezippering for the PannerNode was removed a while ago in https://crbug.com/590000 that added a-rate automation methods. No user bugs have been filed about dezippering being removed.)

Probably the most noticeable effects will come from the GainNode, the DelayNode, and the OscillatorNode.

Edge: No signals (but probably has dezippering)

Firefox: Shipped

Safari: No signals

Web developers: No signals

Ongoing technical constraints

None

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.  As part of the removal, we will have Chrome tests to verify that dezippering is removed.  We are still in the process of upstreaming Chrome’s WebAudio tests to web-platform-tests.

OWP launch tracking bug

http://crbug.com/496282.

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5287995770929152

Requesting approval to ship?

Yes

[Chris Harrelson]

On Thu, Sep 7, 2017 at 10:58 AM, Raymond Toy <rt...@chromium.org> wrote:

Contact emails

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

Spec

http://webaudio.github.io/web-audio-api/

https://github.com/WebAudio/web-audio-api/issues/76

Summary

There are no API changes to WebAudio, but dezippering was removed from the spec in Sep 2015, and we need to remove this from our implementation.

Motivation

WebAudio originally shipped with dezippering support.  When an AudioParam value was set directly with the value setter, the value was not updated immediately.  Instead, an exponential smoother was applied with a time constant of about 10 ms so that the change was done smoothly, limiting any glitches.  It was never very well-specified which parameters had smoothing and what the time constant was.  It wasn’t even obvious if the actual time constant was the appropriate value.

After much discussion, the working group decided to remove dezippering completely from the spec. Now, the value is changed immediately when set. In place of dezippering, it is recommended that developers use the existing AudioParam setTargetAtTime() method to do the dezippering. This is equivalent to the old dezippering, but gives the developer full control on when to apply it, and on how fast to change, and on exactly which parameters should be smoothed.

Removing this reduces developer confusion on what AudioParams have dezippering. This also simplifies the internal implementation in Chrome.

Interoperability and Compatibility Risk

This is potentially a very user-visible change.  For example, if the gain of a GainNode is set, the change will become instantaneous, possibly causing a glitch in the audio.  This didn’t happen before because dezippering was used in the gain value of a GainNode.  Other nodes that have dezippering: DelayNode, StereoPannerNode, BiquadFilterNode, and OscillatorNode,  (Dezippering for the PannerNode was removed a while ago in https://crbug.com/590000 that added a-rate automation methods. No user bugs have been filed about dezippering being removed.)

This sounds like it will most likely be a big problem on some sites. How often is setTargetAtTime used vs not?

Do you have any more data on how big of a problem this change will be?

 

Probably the most noticeable effects will come from the GainNode, the DelayNode, and the OscillatorNode.

Edge: No signals (but probably has dezippering)

Firefox: Shipped

Did Firefox get many bugs filed when removing dezippering?

 

Safari: No signals

Web developers: No signals

Ongoing technical constraints

None

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.  As part of the removal, we will have Chrome tests to verify that dezippering is removed.  We are still in the process of upstreaming Chrome’s WebAudio tests to web-platform-tests.

OWP launch tracking bug

http://crbug.com/496282.

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5287995770929152

Requesting approval to ship?

Yes

--
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/CAE3TgXGrAXR3J767POXYvRBu9SVJ2be%3DTxVD7JWnUswsx%2BEQRw%40mail.gmail.com.

[Raymond Toy]

On Thu, Sep 7, 2017 at 11:59 AM, Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Sep 7, 2017 at 10:58 AM, Raymond Toy <rt...@chromium.org> wrote:

Contact emails

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

Spec

http://webaudio.github.io/web-audio-api/

https://github.com/WebAudio/web-audio-api/issues/76

Summary

There are no API changes to WebAudio, but dezippering was removed from the spec in Sep 2015, and we need to remove this from our implementation.

Motivation

WebAudio originally shipped with dezippering support.  When an AudioParam value was set directly with the value setter, the value was not updated immediately.  Instead, an exponential smoother was applied with a time constant of about 10 ms so that the change was done smoothly, limiting any glitches.  It was never very well-specified which parameters had smoothing and what the time constant was.  It wasn’t even obvious if the actual time constant was the appropriate value.

After much discussion, the working group decided to remove dezippering completely from the spec. Now, the value is changed immediately when set. In place of dezippering, it is recommended that developers use the existing AudioParam setTargetAtTime() method to do the dezippering. This is equivalent to the old dezippering, but gives the developer full control on when to apply it, and on how fast to change, and on exactly which parameters should be smoothed.

Removing this reduces developer confusion on what AudioParams have dezippering. This also simplifies the internal implementation in Chrome.

Interoperability and Compatibility Risk

This is potentially a very user-visible change.  For example, if the gain of a GainNode is set, the change will become instantaneous, possibly causing a glitch in the audio.  This didn’t happen before because dezippering was used in the gain value of a GainNode.  Other nodes that have dezippering: DelayNode, StereoPannerNode, BiquadFilterNode, and OscillatorNode,  (Dezippering for the PannerNode was removed a while ago in https://crbug.com/590000 that added a-rate automation methods. No user bugs have been filed about dezippering being removed.)

This sounds like it will most likely be a big problem on some sites. How often is setTargetAtTime used vs not?

We have UMA stats on how often setTargetAtTime is used, but we have no stats on when the value setter is used. 

Do you have any more data on how big of a problem this change will be?

Difficult to say. I'll ask around and try some popular websites with the changes to see. I will take the lake of bugs from the PannerNode as a good sign since PannerNode is used fairly often.

 

 

Probably the most noticeable effects will come from the GainNode, the DelayNode, and the OscillatorNode.

Edge: No signals (but probably has dezippering)

Firefox: Shipped

Did Firefox get many bugs filed when removing dezippering?

I vaguely recall asking Firefox about this a while back and I think they had no problems; I'll ask again for confirmation.  I also take this is a good sign, but I don't know if webaudio apps regularly test with other browsers.

[Raymond Toy]

It's even simpler. I asked Paul from Mozilla and he said they never actually implemented dezippering except for DelayNode.  He wants to synchronize with us on the removal of the delaynode dezippering.

[Chris Harrelson]

Ok. Did you find any issues when checking some top sites?

If nothing was found there, how about shipping in M64 with a warning message in M63 to help developers mitigate?

[Raymond Toy]

On Wed, Sep 13, 2017 at 11:02 AM, Chris Harrelson <chri...@chromium.org> wrote:

Ok. Did you find any issues when checking some top sites?

I tested with Web Audio demos, Omnitone, Chrome Music Lab, Ableton Learning Music, and bandlab

If nothing was found there, how about shipping in M64 with a warning message in M63 to help developers mitigate?

No problem with doing this, but I'm not sure how beneficial it will be.

Just because you use the setter doesn't mean it will glitch.  And even if there is a glitch, it might be because the setter isn't sample accurate (currently) with respect to the audio context, so even if you replace the setter with a call to setTargetATime, you might still glitch.

I'm not sure what to say in the message either.  Mentioning dezippering might just confuse developers if they don't already know what it is.  And it's not in the spec so it's even more confusing.

Maybe the best thing we can say in the message is that the value setter behavior (for the nodes that have dezippering) will change in M64, with a link to the chrome feature.  We'll probably have to expand the feature entry to include a bit more explanation, probably linking to some more docs.

I'll write up a new intent to deprecate this, with removal by M64.  How's that sound?

I am, however, encouraged that Firefox doesn't have this and there are no bug reports on Firefox for this.  My experience is that many developers run both chrome and firefox when working with webaudio.

[Chris Harrelson]

On Wed, Sep 13, 2017 at 3:07 PM, Raymond Toy <rt...@chromium.org> wrote:

On Wed, Sep 13, 2017 at 11:02 AM, Chris Harrelson <chri...@chromium.org> wrote:

Ok. Did you find any issues when checking some top sites?

I tested with Web Audio demos, Omnitone, Chrome Music Lab, Ableton Learning Music, and bandlab

If nothing was found there, how about shipping in M64 with a warning message in M63 to help developers mitigate?

No problem with doing this, but I'm not sure how beneficial it will be.

Just because you use the setter doesn't mean it will glitch.  And even if there is a glitch, it might be because the setter isn't sample accurate (currently) with respect to the audio context, so even if you replace the setter with a call to setTargetATime, you might still glitch.

I'm not sure what to say in the message either.  Mentioning dezippering might just confuse developers if they don't already know what it is.  And it's not in the spec so it's even more confusing.

Maybe the best thing we can say in the message is that the value setter behavior (for the nodes that have dezippering) will change in M64, with a link to the chrome feature.  We'll probably have to expand the feature entry to include a bit more explanation, probably linking to some more docs.

Sounds good to me. Probably good to say "the quality of your sound output may be affected" or similar.

I'll write up a new intent to deprecate this, with removal by M64.  How's that sound?

Sounds good, thanks.

[Chris Harrelson]

Lgtm1 to ship with the new deprecation plan. No need for a new thread.

[Jochen Eisinger]

lgtm2

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/CAE3TgXGrAXR3J767POXYvRBu9SVJ2be%3DTxVD7JWnUswsx%2BEQRw%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%2Bw9aueVa19Q0b5VBus_AJwZ%2BCUdkQc-vcv5wFdH22Jx3Wg%40mail.gmail.com.

[Dimitri Glazkov]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuifE1%2BxcQDaYYrvkLV9xxxbsreJ0pXZiBOdRZXVNZ9h4Cw%40mail.gmail.com.