- From: <bugzilla@jessica.w3.org>
- Date: Tue, 19 Jun 2012 15:08:44 +0000
- To: public-audio@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 UTC