Intent to Remove: AudioBufferSourceNode.buffer can be set more than once.

40 views
Skip to first unread message

Raymond Toy

unread,
Apr 28, 2015, 1:59:19 PM4/28/15
to blink-dev



Primary eng (and PM) emails

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


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/9-ZId2s0cvw/7BRdlEeqpfgJ


Summary

Give a high-level description of your change. (Fine to copy/paste from “Intent to Deprecate” thread.)


Motivation

We deprecated setting the AudioBufferSourceNode.buffer more than once several months ago and targeted M43 for removal. M43 is beta now, we intend to remove it in M44.


From the deprecation thread:


Allowing the user to set the AudioBufferSourceNode buffer attribute multiple times has issues:

  • Due to the different threads, when the new buffer actually starts playing is not well-defined and goes against WebAudio's goal of sample-accurate playback.
  • The interaction between the properties of the new buffer (length, number of channels, sample rate) and the properties of the AudioBufferSourceNode (start/stop time, looping, grain playback) are are hard to understand and specify.
Not allowing the buffer attribute to be set to a new value once it's been set removes the complications, and behavior is well-specified. This also fits in well with the fire-and-forget philosophy at the heart of WebAudio.

Usage information from UseCounter

According to the UseCounter for AudioBufferSourceBufferOnce, there is no usage of this.


Entry on chromestatus.com

No entry yet on chromestatus, but the entry for deprecation exists.


Compatibility Risk

There is some compatibility risk since this ability was allowed. However, based on the UseCounter metrics, it's very uncommon. Currently all browers support setting the buffer more than once. However, the WebAudio spec does not allow the buffer to be set again after it has already been set. We believe FireFox will disallow setting the buffer more than once.


Chris Harrelson

unread,
Apr 28, 2015, 2:44:59 PM4/28/15
to Raymond Toy, blink-dev
LGTM

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

Philip Jägenstedt

unread,
Apr 29, 2015, 4:43:22 PM4/29/15
to Chris Harrelson, Raymond Toy, blink-dev
LGTM2

TAMURA, Kent

unread,
Apr 30, 2015, 1:34:40 AM4/30/15
to Philip Jägenstedt, Chris Harrelson, Raymond Toy, blink-dev
LGTM3.

--
TAMURA Kent
Software Engineer, Google


Raymond Toy

unread,
Apr 30, 2015, 1:49:16 PM4/30/15
to TAMURA, Kent, Philip Jägenstedt, Chris Harrelson, blink-dev
One quick question.  Do I also go and delete the UseCounter enum and deprecation message?  Seems like I should.

Paul Kinlan

unread,
Apr 30, 2015, 2:07:30 PM4/30/15
to Raymond Toy, TAMURA, Kent, Philip Jägenstedt, Chris Harrelson, blink-dev
Can you also add the removal to Chromestatus.com so that it appears in https://www.chromestatus.com/features#removed, we are trying to make it easier for developers to find and be aware of breaking features.

P

Raymond Toy

unread,
Apr 30, 2015, 6:04:03 PM4/30/15
to Paul Kinlan, TAMURA, Kent, Philip Jägenstedt, Chris Harrelson, blink-dev
On Thu, Apr 30, 2015 at 11:06 AM, Paul Kinlan <paulk...@google.com> wrote:
Can you also add the removal to Chromestatus.com so that it appears in https://www.chromestatus.com/features#removed, we are trying to make it easier for developers to find and be aware of breaking features.



Sorry, I forgot to update this thread with the link earlier.

Philip Jägenstedt

unread,
May 1, 2015, 7:19:08 PM5/1/15
to Raymond Toy, TAMURA, Kent, Chris Harrelson, blink-dev
Yes, deleting the use counter and deprecation message is usually the
thing to do when removing a feature. If the use counter becomes
unreachable it's clearly so, but I would also suggest removing use
counters that served no other purpose than to determine that the
removal was safe even if it's technically possible to keep.

Philip
Reply all
Reply to author
Forward
0 new messages