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:50 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/113/24244414@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#19) by Jussi Kalliokoski on W3C Bugzilla. Mon, 18 Jun 2012 18:56:02 GMT

(In reply to [comment #19](#issuecomment-24244408))
> If so, then "larger buffer sizes" should be a hard requirement. On my fairly
> powerful desktop computer a layout could block for at least 871 ms. The closest
> power-of-two at 48Khz is 65536, i.e. over a second. With that amount of latency
> it doesn't seems very useful.

What? Why would it be a hard limit? Hard limits aren't very future-friendly. Should setTimeout have a minimum timeout limit of 871ms as well? Or requestAnimationFrame?

Developers have to be conscious about performance and avoiding layout reflows anyway, why should this API be any different?

Reply to this email directly or view it on GitHub:
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:24 UTC