[Bug 19991] New: Enable AudioContext to be created in a Worker

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19991

          Priority: P2
            Bug ID: 19991
          Assignee: crogers@google.com
           Summary: Enable AudioContext to be created in a Worker
        QA Contact: public-audio@w3.org
          Severity: normal
    Classification: Unclassified
                OS: Linux
          Reporter: jussi.kalliokoski@gmail.com
          Hardware: PC
            Status: NEW
           Version: unspecified
         Component: Web Audio API
           Product: AudioWG

Currently there are several annoyances to scheduling in the Web Audio API. For
example, if you want to play back a dynamic sequence, you would power it up
with a setTimeout/setInterval, both of which are throttled to once per second
when in a background tab. Now, if you set up a timer that happens once per
second what happens if a reflow or other event delays the timer? To protect
against this, you can schedule events for more than a second at a time, but
it's a tradeoff for responsiveness of the application. Responsiveness or
robustness is not a nice tradeoff to make.

A suggested approach to this problem has been to add a callbackAtTime() method
to the AudioContext, but I fear that introducing yet another timer mechanism to
the main thread won't help much. Say you setup a callback to trigger one second
from the current time. Should it

a) Fire before the clock actually hits the specified time to be a bit more sure
to make it in time?
b) Fire exactly when the clock actually hits the specified time? In this case,
the desired target is most likely missed.
c) Fire after the time? This is a ridiculous idea. :D

Anyway, even that would be suspect to being delayed by other main thread events
like reflows etc., being not much more reliable than a setTimeout(). I think
we're going to get a lot of "no" sound from other working groups and browser
vendors if the callbackAtTime() had no throttling rules, when browsers finally
have painfully put those restrictions to place for existing main thread timer
callbacks, so I don't think we'd get even that advantage.

Hence I'd suggest specifying access to the AudioContext interface from Web
Workers, where one doesn't need to worry about main thread events delaying
anything, nor about timer throttling.

For the time being, the Workers would obviously support less features
(supporting MediaStreamSourceNode and MediaElementSourceNode in the Workers
would require transferring these entities to the Worker as well). One option
would of course be that AudioContexts would be defined as Transferrables, as
well as a AudioNodes, letting graphs be shared across threads. This would
probably actually be the best way to achieve this, provided we can eliminate
race conditions by having value setters and getters exclusive to the thread
that currently has the ownership of each node. But there aren't many critical
features like this in the Web Audio API, which makes it a prime candidate for
being a Transferrable.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 17 November 2012 17:12:36 UTC