Re: Preparing the vote on the data race issue

On Tue, Jul 30, 2013 at 5:45 PM, Marcus Geelnard <mage@opera.com> wrote:

>
>
>
> On Tue, Jul 30, 2013 at 11:24 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> On Mon, Jul 29, 2013 at 3:55 PM, Jer Noble <jer.noble@apple.com> wrote:
>>
>>>
>>> On Jul 29, 2013, at 8:44 AM, Jer Noble <jer.noble@apple.com> wrote:
>>>
>>> >
>>> > On Jul 29, 2013, at 3:35 AM, Olivier Thereaux <
>>> Olivier.Thereaux@bbc.co.uk> wrote:
>>> >
>>> >> My understanding was that Jer's proposal (for lack of a better term -
>>> I know that Jer has said it was not his preferred solution, only a proposed
>>> compromise) was the first one listed in the gist I shared, but I might be
>>> wrong.
>>> >
>>> > Sorry, I've been on vacation for the last week.  I'll clean up that
>>> Gist with the feedback received so far, and narrow it to a single, explicit
>>> proposal.
>>> >
>>>
>>> I’ve updated the gist <https://gist.github.com/jernoble/6034137> to
>>> remove all references to “alternatives” and added a section about memory
>>> and performance considerations.
>>
>>
>> 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.
>>  * I think you want to convert AudioBuffer.channels to be a sequence as
>> well.
>> * 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.
>> * 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).
>>
>>
> ...and as I've suggested before (
> http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0199.html) I
> would really like us to consider replacing AudioBuffers with (ownership
> transferred) Float32Arrays for the AudioProcessingEvent (short version:
> AudioBuffers are mostly off-line generated and static, while the data
> passed to/from an AudioProcessingEvent is purely dynamic and temporary).
>

If we do that, then we should also require those typed arrays to be
neutered when the event handler fully executes which I believe is what Roc
proposed.

--
Ehsan
<http://ehsanakhgari.org/>