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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#41) by Grant Galitz on W3C Bugzilla. Tue, 10 Jul 2012 09:32:21 GMT

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

Except latency for reading back would quite literally kill the emulator. Also the emulator checks how many samples it's under running by in real time do it can run more clocks over the base clocking amount to make sure we actually run 100% speed without this speed adjustment via listening to the sample count, browsers would be underrunning the audio like crazy, as all browsers cheat setInterval timing it seems (aka never call it enough even with extra CPU time free). This was a major reason for the single threaded design, as async buffering from the main thread causes us lag in the speed determination portion, which is unacceptable. It's this measurement that also allows us to prioritize CPU over graphics when hitting the 100% CPU usage wall. We do frame skip by holding off blitting until the end of iteration.

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