Worker Support

[kirbysayshi]

The player currently runs in the main thread. This is fine, as long as the quantum size is relatively large. When using a smaller quantum size, like 256, even shaking the mouse around will often cause dropouts.

There is very little to prevent the player from running in a WebWorker. The only issues are:

• setting up message passing in (easy)
• getting XAudioBuffers out (easy)
• getting XAudioBuffers into the audio driver with less overhead than the main-thread approach (hard)

The ideal approach is probably something like this https://developers.google.com/web/updates/2018/06/audio-worklet-design-pattern#webaudio_powerhouse_audio_worklet_and_sharedarraybuffer. But SharedArrayBuffer is still not enabled in most browsers due to security concerns. And AudioWorklet is unimplemented everywhere but Chrome. In the meantime, an approach like the following might work:

• A new WorkerRenderer is written. It has two components. One component is outside the actual worker, receiving buffers and sending them into a queue, where they are dequeued by the ScriptProcessorNode (or AudioWorklet shim + ring buffer). It also loads and coordinates the worker. One component is within the worker, which loads all the player mechanisms, pumps said mechanisms, and emits transferrrable XAudioBuffers via message passing. So really we have two new renderers: WorkerRendererReceiver (main thread) and WorkerRendererProducer (worker thread).

It's questionable if, for the simple case, the above solution will be more resilient than running on the main thread (especially if we cut down on XAudioBuffer allocations). The power of the NFPlayer isn't really the realtime DSP aspect, more that composition, arrangement, and processing of existant audio. For anything other than immediate user-initiated triggers, a large latency window (8192 samples) is likely ok.