Intent to Deprecate: Setting AudioBufferSourceNode.buffer more than once

[Raymond Toy]

Primary eng (and PM) emails

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

Summary

Historically, WebAudio allowed a user create an AudioBufferSourceNode and assign a new AudioBuffer to the source node as many times as desired. The new AudioBuffer would then get played out through the AudioBufferSourceNode. The W3C Audio group has decided not to allow the buffer to be set to a new buffer after it has been set.

Motivation

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 as 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.

Compatibility Risk

The compatibility risk is unknown but potentially large. This behavior has been allowed since the very beginning of WebAudio and is supported in this way in Chrome, Firefox, and Safari.

Alternative implementation suggestion for web developers

The alternative is to create a new AudioBufferSourceNode and set the buffer appropriately. At the same time, the old AudioBufferSourceNode can be scheduled to stop at the appropriate time, and the new source node scheduled to start at the right time. AudioBufferSourceNodes are designed to be very light-weight objects so this is not a great burden. In return, the transition between the two sources is precisely controlled.

Usage information from UseCounter

There currently is no counter. However, a counter will be added to show how often a buffer is set again after it has already been set.

Entry on chromestatus.com, crbug.com, or MDN

No chromestatus entry yet, but one will be added shortly. We are currently targeting M43 for removal. There is a CL implementing this change.

Requesting approval to remove too?

No, this ability will not be removed at this time. A deprecation message will be displayed and after some period of time with supporting UseCounter data, we can decide to remove it then.

[Philip Jägenstedt]

Non-required LGTM. It seems unlikely that this deprecation message would be triggered often enough to amount to console spam, and being more conservative about it would add ~12 weeks to the deprecation/removal process.

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

[Chris Harrelson]

LGTM