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

Re: New proposal for fixing race conditions

From: Chris Wilson <cwilso@google.com>
Date: Fri, 26 Jul 2013 09:28:21 -0700
Message-ID: <CAJK2wqXD3EmUENZESjthuNu5_3FnPfbLiR8nPJo19fxADNq6ng@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
On Thu, Jul 25, 2013 at 5:23 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Jul 26, 2013 at 6:29 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> The severity issue here I think is rather clear and non-controversial.
>> For content which is affected by this, you'll get corrupted audio playback
>> in case the AudioBuffer is modified on the main thread, or you'll get
>> corrupted audio playback and probably the ability to read memory content
>> that does not belong to you in the case where the ArrayBuffers are neutered
>> by content.  Robert already wrote a very simple test case to demonstrate
>> the first issue.  It would be very interesting to see how easily one could
>> write a test case for the second issue, but I think it will work by
>> basically allocating a large AudioBuffer, neuter the ArrayBuffers by
>> sending them to a worker, connect the AudioBufferSourceNode to a
>> ScriptProcessorNode and examine the contents of inputBuffer.
>>
>
> I already posted a testcase for the second issue. Chris has informally
> proposed to fix it by introducing the concept of "non-neuterable
> ArrayBuffers". I don't think that solution will get past the editors of the
> Typed Array spec (or the TAG, it looks like), but at least we agree the
> issue must be fixed one way or another.
>

Can you point me toward that?  Sorry, this thread has grown beyond
manageability (and yes, I've contributed to that) - but this is a critical
point.
Received on Friday, 26 July 2013 16:28:49 UTC

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