Re: Mutability of the decodeAudioData argument

On Mon, Nov 26, 2012 at 10:37 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

>
>
> On Mon, Nov 26, 2012 at 6:52 AM, Chris Rogers <crogers@google.com> wrote:
>
>>
>>
>> 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.
>>
>
> Sure there is. Pretty much nothing in JS threads is allowed to change
> state during JS execution, otherwise it's considered a bug in the event
> loop and a violation of the HTML5 spec [1].
>

To clarify on this, our case is the other way around, so I'm not sure how
it should work, there are hardly any precedents of passing a mutable data
to an asynchronous function on the web.

However, I don't see any reasonable argument for not neutering the array
buffer. That way we are race-safe and memory-efficient. If the developer
needs a copy of the ArrayBuffer during the decoding operation (I don't see
why), (s)he can always explicitly make one before attempting to decode it.

Cheers,
Jussi


>
>
>> 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.
>>
>
> I don't see where redecoding the ArrayBuffer wouldn't be a bug, after all
> the ArrayBuffer would be restored from neutering after decoding is
> complete, right? So redecoding would be fine after the previous decoding
> operation has been completed; if the developer loses the decoded buffer
> before that, it's probably a bug in his code. I'm not sure why the
> developer would've kept the undecoded buffer around anyway; sure, for
> compressed audio it takes less memory to keep the undecoded buffer instead
> of the decoded one, but if the decoded one is hot you'll just end up using
> more memory and if you eagerly discard the decoded buffer, more CPU as well.
>
> Cheers,
> Jussi
>
> [1] http://dev.w3.org/html5/spec/webappapis.html#processing-model-3
>
>
>>
>>> 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]
>>>
>>>
>>
>