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: Tue, 10 Jul 2012 07:12:15 +0000
Message-Id: <E1SoUcJ-0004KX-Cm@jessica.w3.org>
To: public-audio@w3.org

--- Comment #41 from Marcus Geelnard (Opera) <mage@opera.com> 2012-07-10 07:12:12 UTC ---
(In reply to comment #40)
> 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).

My idea here would be to use time-stamped commands (such as
CYCLE:REGISTER=VALUE), and batch up the commands in a typed array buffer that
is flushed (sent to the worker) once per frame for example. The worker could
run at its own clock with a small latency w.r.t the main thread (I doubt that
it would be noticeable).

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

Read-back is trickier of course. I know very little about the GB/GBC hardware.
My experience is mostly from the SID chip (from the C=64), which allows you to
read back values from one of the oscillators. Here, I think I would just
emulate a very small sub-set of the SID chip in the main thread (those readable
registers were almost never used, and if they were used, it would typically be
for random number generation).

Anyway, these were just some ideas. Perhaps worth trying, perhaps not...

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 Tuesday, 10 July 2012 07:12:19 UTC

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