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 16:44:13 +0000
Message-Id: <E1Sune9-0002La-HD@jessica.w3.org>
To: public-audio@w3.org

--- Comment #71 from Grant Galitz <grantgalitz@gmail.com> 2012-07-27 16:44:12 UTC ---
(In reply to comment #61)
> (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.

Make a mozAudio like access to the API for the main thread. Only sync up when
the main thread pushes new audio or requests for the buffering amount. Firefox
is known to play samples even through GC pauses with mozAudio. It allows the js
dev to pass samples to the browser AND let the browser handle the buffering for
it as well without issuing callbacks.

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 16:44:17 UTC

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