Re: Web Workers

On Wed, Feb 22, 2012 at 7:33 AM, Chris Rogers <crogers@google.com> wrote:

> There is not yet an audio workers implementation in WebKit, but please
> follow this thread:
> http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0225.html
> http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0245.html
>

Sorry, I did not receive these messages and I don't understand why :-(. I
blame GMail... Anyway, to answer Dmitry's questions:

Looking at Robert's example (
> http://people.mozilla.org/~roc/stream-demos/tone.js), the 'onprocessmedia'
> callback allocates a Float32Array on every invocation. This is wasteful and
> degrades performance.
>

Actually you can just rewrite the code like this:

var output;
self.onprocessmedia = function (event) {
  var len = event.audioLength;
  if (!output || output.length < len) {
    output = new Float32Array(len);
  }
  ...
  event.writeAudio(output);
}

The writeAudio method still does a copy. Maybe that copy can be avoided
with an alternative design using transfers, but simply preallocating an
output buffer as Dmitry suggested isn't quite the right solution since an
onprocessmedia handler can output any amount of audio, including none.
Instead we probably should have writeAudio take ownership of the buffer and
neuter it, or alternatively keep the current copy semantics for writeAudio
and have a separate transferAudio method that uses the transfer semantics.

Both current proposals suggest that any worker can handle only one
> JavaScriptAudioNode/ProcessedMediaStream (since the pocessing nodes run a
> predefined callback on the worker).
>

This is definitely not the case for ProcessedMediaStream. There is no
problem with using the same Worker for several ProcessedMediaStreams. If
you want to have different types of processing performed in the same
Worker, you could use a field of the 'params' object in each onprocessmedia
event to distinguish them.

However, I think we should not encourage authors to multiplex processing
nodes onto Workers by hand, since the optimal assignment could depend on
the details of the browser and platform (e.g. how heavyweight Workers are,
and how many cores are available to the browser).

In some UAs (at least in all WebKit-based ones), worker is a relatively
> heavy thing (it is a whole OS thread, as well as associated JS execution
> context resources), so requiring to spawn too many of them is wasteful.
>

I recommend making Workers as lightweight as possible using thread pools
and other such mechanisms. This benefits every application that uses
Workers.

Instead of making params a field of event object, maybe it will be cleaner
> to make params an extra argument to callback, and also pass initial value
> on node/stream construction?
>

I don't understand the benefits of this. Having an event callback with a
single event object parameter is a standard pattern for Web APIs and I
don't see a need to deviate from it here.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]