W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: AudioBuffer mutability

From: Joseph Berkovitz <joe@noteflight.com>
Date: Mon, 29 Oct 2012 21:41:34 -0400
Cc: robert@ocallahan.org, Chris Rogers <crogers@google.com>, public-audio@w3.org
Message-Id: <57299DC0-4A42-48B0-9588-D0E083EC09F3@noteflight.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Ehsan, Robert,

My impression from reading the spec is that neutering would also prevent reading the data in the buffers.  If so, that would be a big problem. Readability (as opposed to mutability) of AudioBuffer data can't disappear just because the buffer is in use.

On Oct 29, 2012, at 6:56 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:

> On Mon, Oct 29, 2012 at 5:41 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> I think in this case this problem is actually easy to solve without even changing the API. The typed array spec defines a "neuter" operation on ArrayBuffers that makes the underlying data inaccessible through the ArrayBuffer and any objects (such as Float32Array) that depend on the ArrayBuffer:
> http://www.khronos.org/registry/typedarray/specs/latest/#9.2
> This is used by Web Workers to enable safe zero-copy transfer of ownership of the data from one thread to another. We could say that, for a given AudioBuffer B, the first time start() is called on an AudioBufferSourceNode whose 'buffer' is B, B's channel ArrayBuffers are neutered. Any future attempts to modify the data will then fail, probably with an "array index out of bounds" error.
> How does that sound?
> This makes the most sense to me.
> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>

... .  .    .       Joe

Joe Berkovitz

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271

Received on Tuesday, 30 October 2012 01:42:05 UTC

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