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

Re: Web Workers

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Thu, 15 Mar 2012 13:30:12 +0200
Message-ID: <CAJhzemXLWToQHEino=XgrX=hCms8MgQQiLTZLU5D0oLt7-5NCQ@mail.gmail.com>
To: robert@ocallahan.org
Cc: Dmitry Lomov <dslomov@google.com>, Chris Rogers <crogers@google.com>, Alistair MacDonald <al@signedon.com>, public-audio@w3.org
On Thu, Mar 15, 2012 at 1:29 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> Is postMessaging your samples to a Worker for playback a problem for
>> either of those cases?
>>
>
> Prety much yeah, that would make the suboptimal case even more so. It
> would be overtly difficult to get it reliable, even more so than with Audio
> Data API. To keep track of buffer underflows, you'd have to poll the worker
> for status, asynchronously, then hope the message containing the audio
> buffer got there in time, and/or invent your own timer system for the
> callbacks to fill the buffers (quite CPU-intensive, I can tell, and for
> both of these cases CPU cycles are quite valuable), and to keep it working
> in background tabs, you'd have to resort to means similar I'm using for the
> Audio Data API in sink.js (a Blob URI generated worker sends the timer
> beacon, not nice to waste a worker context on a simple timer, although it
> can be cramped up in the same timer as the worker processor).
>

s/timer as the worker/worker as the stream/


>
> In summary, not a good idea.
>
> Cheers,
> Jussi
>
Received on Thursday, 15 March 2012 11:30:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 March 2012 11:30:44 GMT