Re: Mutability of the decodeAudioData argument

On Tue, Nov 20, 2012 at 2:43 PM, Chris Rogers <crogers@google.com> wrote:

> On Mon, Nov 19, 2012 at 5:10 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> 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?
>

"Neutering the buffer to be read-only" isn't currently defined or
implemented anywhere, though.

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.
>

Don't you want to avoid having to copy the data?

Is there a problem with neutering the buffer?

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]