Re: Proposal for fixing race conditions

On Thu, Jun 27, 2013 at 8:16 AM, Jer Noble <jer.noble@apple.com> wrote:

> Any option which will cause ArrayBufferViews to be neutered will cause
> performance regressions in unrelated ArrayBufferView code paths.  Neutering
> (ala workers) destroys some of the optimizations which our JavaScript
> interpreter can make for regular buffer access: once any ArrayBuffer is
> neutered, the interpreter must begin to perform neuter checks before any
> accessing any ArrayBuffer.  Given that the primary clients of the WebAudio
> API will be browser games, and given that game engines will (through asm.js
> or otherwise) make heavy use of ArrayBufferViews, this could be a very
> significant performance regression. So I would not support any spec
> language which would require neutering during the normal course of
> playback.  Apart from the performance implications, this behavior is also
> extremely complicated and would be an ongoing drag on engineering resources.
>

The performance issue seems like something you'd want to fix anyway,
because performance-intensive code using workers is likely to trigger
buffer neutering. And, having implemented this behavior for AudioBuffer, I
don't find it very complicated. But if we can find something better, great.

That said, I'd like to make an alternative proposal that will have
> acceptable performance costs, simplify implementations, and be
> understandable to web developers.  It all follows from one change:
>
> * AudioBuffers are immutable.
>
> Once data has been added to an AudioBuffer, it can no longer be modified.
>  Data passed into the AudioBuffer will be copied internally.
>  getChannelData() will return a copy of the AudioBuffer's contents.
>  Currently, developers are filling AudioBuffers with synthesized audio by
> calling getChannelData().set(), so we will need to add a
> AudioContext.createBuffer() which takes sampleRate and numberOfChannels
> arguments. (I believe such a change was being considered anyway.)
>

I assume you meant to say that this createBuffer() overload would
additionally take a list of Float32Arrays as parameters.

I like this proposal better than doing nothing. However, it would break
every existing application that uses the "createBuffer(numberOfChannels,
length, sampleRate)" overload, which is a problem IMHO. In fact that method
would just go away since it would be useless.

An alternative, somewhere between your proposal and my proposal, would be
to say that AudioBuffers created by means other than
"createBuffer(numberOfChannels, length, sampleRate)" are immutable, and
AudioBuffers created by "createBuffer(numberOfChannels, length,
sampleRate)" are mutable via getChannelData() but only until the first
"acquire the buffer contents" operation, at which point the data is copied
and the buffer becomes immutable. This would have the same performance
characteristics as your proposal, be just a little more complex than your
proposal, but be compatible with most usage of
"createBuffer(numberOfChannels, length, sampleRate)".

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*