Re: Preparing the vote on the data race issue

On Tue, Jul 30, 2013 at 11:46 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> 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.
>
>
Exactly. I think it's the best solution for the AudioProcessingEvent.
Especially with Jer's proposal (which IMO makes it clearer that
AudioBuffers belong to the audio engine), it makes even more sense to use
typed arrays + neutering for the AudioProcessingEvent (which should be very
tightly coupled to the audio engine, IMO).

/Marcus


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