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

Re: Mutability of the decodeAudioData argument

From: Chris Rogers <crogers@google.com>
Date: Mon, 19 Nov 2012 17:43:32 -0800
Message-ID: <CA+EzO0knkHjiDv0Ln-iEry0Nszy1sA32vms42coH-fOhXy3g7g@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: public-audio@w3.org, "Robert O'Callahan" <robert@ocallahan.org>
On Mon, Nov 19, 2012 at 5:10 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> Hi everyone,
> Continuing from the discussion that roc started about the mutability of
> AudioBuffers, we also need to specify what should happen if the author
> tries to modify the ArrayBuffer argument of decodeAudioData.  If we want to
> allow mutability, then the implementation either has to copy the buffer
> eagerly or apply some kind of a copy on write mechanism on top of it, both
> of which can be expensive for big buffers.
> Another approach which might make sense would be to neuter the ArrayBuffer
> so that the author cannot access the contents of the ArrayBuffer after
> starting a decode operation.

I assume you mean neuter the buffer to be read-only, since writing to the
ArrayBuffer in the main JS thread *while* the decoding is currently
underway is what we're worried about?

Instead of messing around with neutering, I also think that an
implementation can simply make a temporary copy during the time it's
decoding the data.  It can then release this copy of the undecoded data as
soon as the decoding process has finished.  This way the memory-hit is
temporary and is typically for a very short period of time.


> What do people think about this solution?
> Thanks!
> --
> Ehsan
> <http://ehsanakhgari.org/>
Received on Tuesday, 20 November 2012 01:43:59 UTC

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