- From: Joseph Berkovitz <joe@noteflight.com>
- Date: Tue, 19 Oct 2010 18:56:16 -0400
- To: Chris Rogers <crogers@google.com>
- Cc: public-xg-audio@w3.org
Hi Chris, I'm a little puzzled by your response on this point -- I understand the perils of heavy thread traffic, but my proposal is designed to decrease that traffic relative to the current API, not increase it. I'm proposing a mechanism that basically prevents events from being dispatched to JavaScriptAudioNodes that don't need to be serviced because their start time hasn't arrived yet. It seems to me that this approach actually cuts back on event listener servicing. Without such a filtering mechanism, many AudioProcessingEvents are going to be fired off to JS nodes, which will look at the event playback time and then return a zero buffer because they discover they're quiescent. This seems like a waste of cycles to me. Wouldn't it be better to have the audio thread understand that there is no need for JS invocation on these nodes much of the time, and zero out the audio output on their behalf? I totally understand your concerns about reliability and robustness. I'm certainly willing to go to the codebase and demonstrate the feasibility of what I'm proposing, but would it perhaps make sense for us to have a direct implementation-level conversation first? I'm not sure email is working very well here as a communication mechanism. Best, ...Joe On Oct 19, 2010, at 5:27 PM, Chris Rogers wrote: > Joe, > > I understand that it could be implemented to work as you suggest > without adding a large amount of code, but the point is that there > could still be a large amount of traffic between the audio thread > and the main thread with large numbers of event listeners being > fired near the same time (for overlapping notes). The handling of > timers and event listeners on the main thread is fairly dicey and is > in competition with page rendering and other JavaScript running > there. There's also garbage collection which can stall for > significant amounts of time. I know that to some extent we're > already accepting this scenario by having a JavaScriptAudioNode in > the first place. But, the API system you're proposing encourages > the possibility of many more event listeners needing to be serviced > in a short span of time. > > That said, you're free to take the WebKit audio branch code and try > some experiments there. My concern is mostly oriented around the > reliability and robustness of the system when pushed in different > ways, run on a variety of platforms (slow and fast), and combined > with other stuff going on in the rendering engine like WebGL and > canvas drawing.
Received on Tuesday, 19 October 2010 22:56:54 UTC