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:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244414
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