- From: <bugzilla@jessica.w3.org>
- Date: Fri, 27 Jul 2012 07:54:13 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415 --- Comment #61 from Marcus Geelnard (Opera) <mage@opera.com> 2012-07-27 07:54:13 UTC --- (In reply to comment #52) > There's always some lag with comm to a webworker, and losing the direct ability > to be called for refill on the same thread for audio makes the entire web app > vulnerable to lag spikes in webworker communication. I saw this with the > MediaStream API, where sync backs would be bunched up too much causing too much > inconsistency and thus gaps. I haven't looked into the worker communication lag part, but I don't really see a fundamental reason why it has to be a problem. On the other hand, doing audio callbacks on the main thread will always be problematic, and I don't see how it could ever be solved. I envision a design where the audio mixer is running in a separate thread (or possibly multiple threads for graphs with independent processing chains). Whenever a node is encountered that needs data from a main thread callback, the mixing thread will have to halt and wait until the main thread callback has fired and finished, which is very sensitive to other things that may be going on in the main thread (e.g. a setInterval/requestAnimationFrame event). I'd much more prefer a solution that does not require the audio mixing thread to be halted just to fire an event on the main thread. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Friday, 27 July 2012 07:54:15 UTC