- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 27 Nov 2012 00:17:46 +1300
- To: Chris Rogers <crogers@google.com>
- Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-audio@w3.org
- Message-ID: <CAOp6jLYiQsmWgnwF5J0QBCvUS87jKUpXXzoXOau6kM9-8VULyQ@mail.gmail.com>
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