Re: Audio Workers - please review

On Mon, Aug 25, 2014 at 1:20 PM, Joseph Berkovitz <joe@noteflight.com>
wrote:

> It looks as though your “tweak” is collapsing the AudioWorker and
> AudioWorkerNode. [It would be great if you could capture tweaks like this
> in the github issue comments, for easier tracking.] Offhand I don’t see a
> problem with this since they should be in a 1:1 relationship and this
> simplifies the developer’s world.
>

That was part of the previous proposal, actually.  But yes.  Pasted into GH
issue.


> - Do we need to provide some distinctive treatment for k-rate AudioParams,
> resulting in a one-element value array (and corresponding efficiencies in
> the audio engine not bothering with frame-rate ramping etc)? It feels right
> to me, and knowing the rate of such params might enable some kinds of
> browser optimizations in the future. I think all we need is a 3rd argument
> specifying the rate on AudioWorkerNode#addParameter.
>

I thought through this, and discussed with Raymond beforehand.  I'm open to
adding this, but it wasn't clear if you'd need a more definitive statement
that "this is a k-rate AudioParam" than the fact that the arrays only have
one element.  And, of course, all this saves is the generation of 127
entries in the block based on the scheduling; k-rate params can simply
ignore them.  I simply avoided the complexity in this proposal, happy to
add if there's some rough consensus we should do so.


> - Is there a necessary overhead and concomitant GC expense involved in
> creating the Float32Arrays for each AudioProcessingEvent? (I’d imagine not,
> but it’d be good to know what browser implementors think.)
>

No.  Specifically: you should be able to (and should - I can make this
stronger in the text if desired) reuse the memory used for the
Float32Arrays (as well as the AudioBuffer objects themselves).  As there's
no cross-thread issue here, race conditions should not be a concern.