- From: Joe Berkovitz <joe@noteflight.com>
- Date: Thu, 29 Jan 2015 18:49:47 -0500
- To: Audio Working Group <public-audio@w3.org>
- Message-ID: <CA+ojG-ZpTc3D5oGLZqsa7XvTMQMuizSWEprEoNMAUVEhsAUJ5w@mail.gmail.com>
Hi group, It was great seeing so many of you in person in Paris. In the spirit of keeping the discussion moving on AudioWorker, I've posted a version of the spec that embodies the idea of AudioWorker acting as a factory for AudioWorkerNodes. This allows AudioWorkerNodes to be created synchronously (or, at least, as synchronously as native nodes), because the script loading phase only occurs once up front, when an AudioWorker is created. The nodes for that worker are created later, after the AudioWorker is up and running and its script has run. The AudioWorkerGlobalScope now has an onaudionodecreated handler, called each time the factory makes a new node. That in turn takes care of attaching an onaudioprocess handler to the newly created node, as well as doing whatever other setup is needed for the node. You can see my proposal here: http://joeberkovitz.github.io/web-audio-api/ I suggest jumping straight to the reworked bitcrusher / VU-meter sample code snippets to get the idea and then reading the revised/added interface definitions. Overall it's not far from Jussi's proposal from Sept. 2014 in terms of overall concept and naming. There are some differences though. Also, it's forked from Chris Wilson's last published revision and incorporates Chris's work on the configurable-input-output changes. Diffs in my version can be viewed here: https://github.com/joeberkovitz/web-audio-api/commit/0581c5bddfdacf1e9bef075f91dc76c18e186bda A few other highlights for possible discussion: 1. I moved the configuration of node parameters and inputs/outputs into the worker script. The argument that these things must be configured in the main thread prior to node creation no longer applies (since the entire AudioWorker script now runs prior to node creation). From a packaging point of view it seemed much nicer to have these shared characteristics of nodes defined in the script, not the main thread -- Norbert Schnell raised this issue at the WAC conference. However, this does imply that a single AudioWorker can't leverage its script to somehow create nodes with different AudioParams or input or output configurations. Others might feel differently about this tradeoff. 2. I allowed the node-creation method on AudioWorker to pass some initial Transferable data for the new node, because it felt analogous to the constructor args taken by most native nodes. Maybe this amounts to sugar in place of explicitly calling postMessage() on the node immediately after its creation, as in Chris's VU meter example. So perhaps this extra data-passing opportunity should be taken out -- but I thought the creation event for a node was special enough to merit some data being passed in to initialize it. Anyway, hope this is helpful. I'm sure it needs lots more critiquing and work. ...Joe
Received on Thursday, 29 January 2015 23:50:23 UTC