Re: Preparing the vote on the data race issue

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

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

I think this would be a good idea.

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