W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: Audio Workers - please review

From: Joseph Berkovitz <joe@noteflight.com>
Date: Fri, 12 Sep 2014 10:55:26 -0400
Cc: Ehsan Akhgari <ehsan@mozilla.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
Message-Id: <E75982B6-9CDF-4167-A9F8-31C8C69F7FE9@noteflight.com>
To: Chris Wilson <cwilso@google.com>

On Sep 12, 2014, at 9:02 AM, Chris Wilson <cwilso@google.com> wrote:

> I do want to be clear, by the way - sorry, I'm travelling, and somewhat distracted - on two points:
> 1) I do not believe arbitrary parallelization of the graph is a good idea. It will be moderately difficult to examine the graph to decide that it's "okay" to parallelize (i.e. that there are no interconnections or other dependencies), and far worse, the process will needfully insert latency into the graph.  I believe if authors think they should parallelize their app, they can do that (with workers and inserting their own latency) - I've discussed this with a couple of pro audio app builders, and they were comfortable with this.  (that is to say: you don't get arbitrary parallelization as optimization in any other system I know of.  It has side effects.)

[See my later response to your followup.]

> 2) I'm not optimistic about trying to batch nodes together just in order to save some instantiation cost.  I'd far rather run this by the TAG and script-coord, because I feel that's not the right optimization.

Thanks — it sounds like this is at least a partial, initial answer to my question re: Jussi’s issues about the startup costs of a worker that utilizes libraries. I would hope that there are ways to minimize the overhead of creating what amount to identical execution contexts for the same scripts.

Received on Friday, 12 September 2014 14:56:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC