Re: Preparing the vote on the data race issue

On Jul 30, 2013, at 2:24 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:

> Thanks for doing this, Jer!
> 
> A few issues about your proposal:
> 
> * In the AudioBuffer constructor, I believe you want to accept a sequence, not an array.

This implies the contents are copied, so sure, I’ll make this change.

> * I think you want to convert AudioBuffer.channels to be a sequence as well.

I don’t think so, as the Web IDL spec says "Sequences must not be used as the type of an attribute, constant or exception field."

> * Should AudioProcessingEvent.outputBuffer be nullable?  I don't think that it makes sense to require the implementation to allocate an object (even lazily) if it's going to be overwritten in the typical use case.

In the ideal world, we don’t want mallocing to occur inside the AudioProcessingEvent handler, and definitely not during the normal course of action, so by default outputBuffer should always point to a valid AudioBuffer.  I guess assigning ‘null’ to outputBuffer would be fine, and would be treated as silence by downstream nodes, but since it would be no different than the default, I don’t see what value allowing it to be nullable would add.

> * Float32Array is not a regular Web IDL interface <http://www.khronos.org/registry/typedarray/specs/latest/#7> so you cannot extend it with the partial interface syntax (AFAIK).

We should get a final answer to that question.  If it turns out that we can’t extend Float32Array, a functionally equivalent replacement method copyTo() has been suggested as a drop-in replacement.

-Jer