Re: Preparing the vote on the data race issue

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

/Marcus


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