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: Mon, 09 Jul 2012 17:27:21 +0000
Message-Id: <E1SoHk1-0004kG-Cg@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #40 from Grant Galitz <grantgalitz@gmail.com> 2012-07-09 17:27:20 UTC ---
(In reply to comment #39)
> (In reply to comment #38)
> > To sum up my argument: We are currently not provided all the resources inside a
> > webworker to attain full independence from the main thread yet, and dependence
> > on the main thread kills us with i/o lag.
> 
> A possible solution for emulators like the JS GBC emulator (which I really
> like!): move the audio emulation part to a Web worker (making it independent
> from the main thread), and post time-stamped audio HW register writes from the
> main thread to the audio Web worker (should be quite compact data?). That way
> you would be glitch free even in cases of i/o lag. This assumes that you can do
> the audio HW emulation independently from the rest of the machine, but for
> simple "8-bit" sound HW, I think it can easily be done.

One possible problem with that is we would need to synchronize up to once every
two clocks at a sample rate of 4194304 hertz (One sample per clock cycle for
LLE emulation). We also would need to synchronize back part of the audio state,
as we expose some of the state back in the emulated hardware registers.

-- 
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 Monday, 9 July 2012 17:27:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 July 2012 17:27:23 GMT