W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: Web Workers

From: Dmitry Lomov <dslomov@google.com>
Date: Thu, 1 Mar 2012 13:58:02 -0800
Message-ID: <CAObu7DERSm9b_yayJ8we1v3i5hqm_t87sv3sDj_r+Ri=ry6=uw@mail.gmail.com>
To: robert@ocallahan.org
Cc: Alistair MacDonald <al@signedon.com>, Chris Rogers <crogers@google.com>, public-audio@w3.org
On Wed, Feb 29, 2012 at 2:52 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Feb 22, 2012 at 5:34 AM, Alistair MacDonald <al@signedon.com>wrote:
>
>> ROC, I noticed I could not get access to audio data with the MediaStreams
>> API without using a Worker thread (using your recent builds and demos).
>> Jussi said he believes this the case too. Could you confirm this? If so -
>> is this by-design? I am trying to figure out whether there is a technical
>> suggestion of dropping JavaScript Processing of audio data from the
>> main-thread all-together, or is this was merely a matter of tackling the
>> Worker code as a priority.
>
>
> Main-thread access to audio data may not be necessary, since it's easy for
> a Worker to use postMessage to communicate to/from the main thread. For
> example, see
> http://people.mozilla.org/~roc/stream-demos/analyzing-audio.html
> http://people.mozilla.org/~roc/stream-demos/sample-fetcher.js
> The worker code is literally
> self.onprocessmedia = function(event) {
>   var msg = {
>     channels: event.audioChannels, rate: event.audioSampleRate,
>     samples: event.inputs.length > 0 ? event.inputs[0].audioSamples : null,
>   };
>   postMessage(msg);
> };
> If the demo needed any processing at all of the data, performance would
> improve by doing that processing in the worker so you'd be winning by
> having the worker involved.
>
> There may be scenarios where direct main-thread audio data processing is a
> significant win over Worker+postMessage, e.g. due to reduced overhead
> and/or convenience. I don't know yet. If those scenarios are non-existent
> or extremely rare, then *not* having main-thread audio data processing APIs
> is simpler and encourages authors to do the right thing by using Workers as
> much as possible.
>
> So right now I do not know whether having API support for main-thread
> audio data processing is a good idea.
>

FWIW, I concur. Main-thread audio-processing, due to a real-time nature of
the latter, would introduce contention with a primary purpose of the main
thread (which is rednder as fast as possible and react to user input
quickly).


>
> 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]
>
>
Received on Thursday, 1 March 2012 21:58:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 March 2012 21:58:31 GMT