Re: [web-audio-api] It makes no sense to use EventListener for onaudioprocess if ScriptProcessorNode isn't EventTarget (#116)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=20764#5) by Srikumar Subramanian (Kumar) on W3C Bugzilla. Tue, 19 Feb 2013 08:04:40 GMT

(In reply to [comment #5](#issuecomment-24244307))

> Also the usage of callbacks can enable us clean up the API by accepting the
> callback as an argument to the createScriptProcessor function, which makes
> it unnecessary to expose it on ScriptProcessorNode at all.  Speaking of
> which, I don't think exposing bufferSize on that node type makes much sense
> either.

It is useful to be able to change the callback after creating the script node. Please lets not change that.

Exposing buffer size is also useful. The script node currently shares CPU with the main thread. Given this architecture, the amount of time available for audio can be different for different kinds of applications. A graphics rich application may not be able to guarantee enough callbacks just in time, in which case longer buffers would be desirable. An application that spends most of its time doing audio or being idle can use smaller buffer sizes to get lower latency. It is unnecessary to mandate an implementation to automatically determine the required buffering.

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