W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: Preparing the vote on the data race issue

From: Jer Noble <jer.noble@apple.com>
Date: Tue, 30 Jul 2013 15:42:20 -0700
Cc: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, Joseph Berkovitz <joe@noteflight.com>, WG <public-audio@w3.org>
Message-id: <2576941C-A0C4-41D6-A290-47F4388BA65C@apple.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>

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.

Received on Tuesday, 30 July 2013 22:42:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC