Re: [web-audio-api] (JSWorkers): ScriptProcessorNode processing in workers (#113)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#40) by Marcus Geelnard (Opera) on W3C Bugzilla. Tue, 10 Jul 2012 07:12:12 GMT

(In reply to [comment #40](#issuecomment-24244539))
> 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...

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244543