- From: <bugzilla@jessica.w3.org>
- Date: Tue, 19 Feb 2013 08:04:40 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20764
Srikumar Subramanian (Kumar) <srikumarks@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |srikumarks@gmail.com
--- Comment #6 from Srikumar Subramanian (Kumar) <srikumarks@gmail.com> ---
(In reply to comment #5)
> 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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 19 February 2013 08:04:46 UTC