- From: Chris Rogers <crogers@google.com>
- Date: Mon, 19 Nov 2012 17:43:32 -0800
- To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Cc: public-audio@w3.org, "Robert O'Callahan" <robert@ocallahan.org>
Received on Tuesday, 20 November 2012 01:43:59 UTC
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. Chris > > What do people think about this solution? > > Thanks! > -- > Ehsan > <http://ehsanakhgari.org/> >
Received on Tuesday, 20 November 2012 01:43:59 UTC