Re: Mutability of the decodeAudioData argument

On Thu, Nov 22, 2012 at 2:37 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

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

First of all we need to determine if it's even necessary to worry about
potential raciness with modifying the ArrayBuffer *while* it's being
decoded.  At worst, I think it basically amounts to the JS code corrupting
the data so that it would simply result in a decoding error.  This is not
that much different from some JS code writing random bytes into the
ArrayBuffer before the decode operation is started.  In either case, it's a
pretty strange thing to do and a developer shouldn't be surprised if that
results in a decoding error.


> Is there a problem with neutering the buffer?
>

If it were neutered, I'm foreseeing problems where developers keep the
ArrayBuffer of undecoded audio data around and call decodeAudioData() a
second time and it would fail.  It seems like there would be legitimate
cases where it would be desirable to be able to re-decode if the originally
decoded AudioBuffer is no longer available, has been garbage collected, etc.


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