W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:54 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/113/24244435@github.com>
> [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
Received on Wednesday, 11 September 2013 14:30:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC