The traffic for this runnable is high, and we can’t make it lower by just sending less runnables, I’ve tried, and it’s a disaster for Web Audio API. We should check if we really need this timing info on the main thread (I don't think it's useful, it's only used for {AudioContext, HTMLMediaElement}.currentTime), and possibly use atomics for those frequent updates.

Those runnables are frequent, but are not very expensive.