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

Re: New proposal for fixing race conditions

From: Jer Noble <jer.noble@apple.com>
Date: Mon, 29 Jul 2013 11:27:23 -0700
Cc: Robert O'Callahan <robert@ocallahan.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
Message-id: <66CB2C6C-05B4-4A21-ADEF-5222407A59A9@apple.com>
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>

On Jul 29, 2013, at 11:21 AM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:

> On Mon, Jul 29, 2013 at 6:52 PM, Jer Noble <jer.noble@apple.com> wrote:
> On Jul 25, 2013, at 5:23 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> 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.
> To be clear, WebKit has already fixed this issue (and so, I believe, has Blink), without exposing "non-neuterable ArrayBuffers" to the web.  We did introduce the concept of non-neuterable buffers internally, but only as an implementation detail, and that detail is not web-exposed.
> How is that not web-exposed when it makes some array-buffers non-neuterable? I think that's very observable behavior and needs to be specced.

It only makes the internal AudioBuffer data structures non-neuterable.  All ArrayBufferViews (and their associated ArrayBuffers) returned by AudioBuffer.getSourceData() remain neuterable (and neutered).


Received on Monday, 29 July 2013 18:28:16 UTC

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