Re: Proposal for fixing race conditions

On Jun 26, 2013, at 3:18 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> I assume you meant to say that this createBuffer() overload would additionally take a list of Float32Arrays as parameters.

Yes, exactly.  As an aside, the "getChannelData(x).set(y)" technique this would be replacing also involves a copy, so there is no performance loss here.

> I like this proposal better than doing nothing. However, it would break every existing application that uses the "createBuffer(numberOfChannels, length, sampleRate)" overload, which is a problem IMHO. In fact that method would just go away since it would be useless.

Yes, this proposal would either deprecate or elimanate that function. (See below.)

> An alternative, somewhere between your proposal and my proposal, would be to say that AudioBuffers created by means other than "createBuffer(numberOfChannels, length, sampleRate)" are immutable, and AudioBuffers created by "createBuffer(numberOfChannels, length, sampleRate)" are mutable via getChannelData() but only until the first "acquire the buffer contents" operation, at which point the data is copied and the buffer becomes immutable. This would have the same performance characteristics as your proposal, be just a little more complex than your proposal, but be compatible with most usage of "createBuffer(numberOfChannels, length, sampleRate)".

I was trying to avoid a situation where the mutability of an AudioBuffer depended greatly on whether it had been added to an AudioNode.  That's a very confusing story for web developers. (And implementors!)

To avoid breaking existing content, perhaps this can be left in the prefixed version of the API but removed from the unprefixed one.  Keep in mind, however, that pages who assume the mutability of AudioBuffers created through other means will still break, so if we go down the immutability path it may be best to rip the bandage off all at once.

-Jer