Re: [web-audio-api] (JSWorkers): ScriptProcessorNode processing in workers (#113)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#22) by Jussi Kalliokoski on W3C Bugzilla. Tue, 19 Jun 2012 14:41:03 GMT

(In reply to [comment #21](#issuecomment-24244423))
> (In reply to [comment #20](#issuecomment-24244414))
> > Developers have to be conscious about performance and avoiding layout reflows
> > anyway, why should this API be any different?
> 
> One problem is that developers don't control all the pages that might possibly
> be sharing the same thread. No browser puts every page on its own thread. So
> even if you write your page perfectly, you're still vulnerable to latency
> caused by poorly-written pages sharing your main thread.

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244435