W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Fri, 27 Jul 2012 07:54:13 +0000
Message-Id: <E1SufNF-00020v-VS@jessica.w3.org>
To: public-audio@w3.org

--- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC