W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Jun 2012 15:08:44 +0000
To: public-audio@w3.org
Message-Id: <E1Sh02u-0007F4-6Z@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #26 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-06-19 15:08:43 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
> > (In reply to comment #21)
> > Of course, but this argument is just as valid against having an audio API at
> > all, after all the developer can't anticipate what else is running on the
> > user's computer aside from the browser. For all the developer knows, the API
> > might be running on a mobile browser with all cores (or maybe just one) busy.
> > Throwing more threads at it doesn't necessarily solve the problem of not being
> > able to anticipate all situations.
> 
> True, but there is a significant difference between running several threads on
> a single core (preemptive scheduling should give any thread CPU quite often),
> and running several pages in a single thread (a callback may have to wait for
> seconds).

Still, no matter what we do, in some cases audio will not work as expected,
will miss refills, and there's nothing we can do about it. What we can do,
however, is give the proper tools to handle these situations, including main
thread audio processing that doesn't have to resort to manually transferring
audio to a worker (or graphics to the main thread either), because that's even
more expensive and likely to fail.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 19 June 2012 15:08:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 15:08:47 GMT