Re: Audio Workers - please review

Hi Chris,

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.

Everything else about script processing looks good including the new AudioParam creation concept, but I think it would be good for the WG to address the following questions from the prior threads of discussion (forgive me if you did and I’ve missed it):

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

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

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"


On Aug 25, 2014, at 11:29 AM, Chris Wilson <cwilso@google.com> wrote:

> I've done some tweaking to the Audio Worker (issue #113) proposal, and most significantly added the ability to create AudioParams on Audio Workers (issue #134).
> 
> The fork is hosted on my fork (http://cwilso.github.io/web-audio-api/).  Start here to review the creation method, and the bulk of the text begins at http://cwilso.github.io/web-audio-api/#the-audio-worker.