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

Re: Mutability of the decodeAudioData argument

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 27 Nov 2012 00:17:46 +1300
Message-ID: <CAOp6jLYiQsmWgnwF5J0QBCvUS87jKUpXXzoXOau6kM9-8VULyQ@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-audio@w3.org
On Mon, Nov 26, 2012 at 5:52 PM, Chris Rogers <crogers@google.com> wrote:

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

As I've mentioned before, we've worked hard to keep data races out of the
Web platform and I will be embarrassed if we introduce them in Web Audio
without extraordinary justification.

Concurrent modification to the input buffer is very different to
modification before decoding begins. How sure are you that your codecs are
resilient to concurrent modification of their input buffers? E.g. are you
sure that your codecs don't contain any code like
  if (buffer[N] >= MAX_TOKEN_VALUE)
    return ERROR;
  v = token_list[buffer[N]];
?

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

Normally authors would just retain a reference to the decoded AudioBuffer
instead of redecoding, would they not? Why would they want to redecode?

In any case, if they want to redecode later for some reason, then they
could make their own copy of the ArrayBuffer before decoding. As long as
browsers are consistent about neutering the decoded ArrayBuffer, authors
will quickly discover what's required.

We could restore the neutered ArrayBuffer after decoding has finished, as
Jussi suggested, if that helps. I'm not sure when it would be useful though.

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]
Received on Monday, 26 November 2012 11:18:15 UTC

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