Some further information:
The 'arbitrary units of work' that a Web Audio scheduler would run would be the music notes and audio params. To picture this lets say we have a frame/slice of notes pulled out of a score of data using RxJS pipeline operators. Each note in the quantized time frame/slice still has it's own fine durational timing. Each note event then needs to be scheduled as an 'action' in the Web Audio scheduler. The scheduler then pushes out each scheduled note to the Web Audio context/thread at the scheduled time (or maybe it flushes all the notes instead?).
What is key is to switch to the Web Audio scheduler (maybe using observeOn) just as the notes are scheduled and sent to the Web Audio context. The essential thing is to use the Web Audio clock to know when to schedule each note. So in the over all pipeline this vital aspect has to be done outside the standard RxJS schedulers to avoid the jitter and low-resolution that comes from using setInterval and setTimeout, which are based on the System clock not the high-resolution Web Audio clock.
The Web Audio world has had an imperative workaround solution to setInterval and setTimeout for a few years now using a hack. Now in this new functional and reactive age we have a great opportunity to fix this hack. What I and the rest of the musical world would really appreciate is if RxJS experts like yourself would take a good look at the following article and it's demo. Please note also that the demo schedules visuals using RAF and then separately schedules the audio notes using the workaround hack. It is this hack that a new RxJS scheduler for Web Audio would improve upon.
html5rocks.com/en/tutorials/audio/scheduling webaudiodemos.appspot.com/metronome/index.html github.com/cwilso/metronome