w3c
change: Expose Performance interface to AudioWorklet
Closes https://github.com/WebAudio/web-audio-api/issues/2413
The Audio Working Group would like to ask that self.performance.now() be exposed in AudioWorklet.
There is desire from the Web Audio community, and positive comments from browser implementers (please refer to the linked issue).
Implementation commitment:
- [ ] WebKit (no signal)
- [x] Chromium
- [ ] Gecko (positive based on issue comments and meeting)
One conclusion from discussing this at the WebPerfWG call - we need to verify that the crossOriginIsolated references in the HR-time algorithms work well in worklets
There is still interest from the Web Audio community in this change. Would it be possible for me to join a WG call to help with any blocking tasks, or perhaps we could discuss this at TPAC this year?
We can discuss this on the next call, on August 28th 10am PT. Would that work for you?
Yes that would work, thank you. I can see the call details on the W3C site; do I need to do anything beforehand or can I just join the call directly as a guest?
Thank you for including me in the meeting today. Here are my notes:
- AudioWorklet use cases center around accurate sample timing, but there are multiple developers with different applications requesting the feature so there are many possible use cases.
- Performance.now uses different granularity based on if the document is cross-origin isolated or not. WebAudio applications sometimes use SharedArrayBuffer which requires cross-origin isolation, and sometimes do not, so we expect AudioWorklet applications to be running in both modalities.
- It's probably not necessary that the timer object on the AudioWorklet be the same as the timer object on the main thread. The main goal is to get a high-resolution timer on the AudioWorklet.
- There is a question of if this should be exposed on other worklets, such as PaintWorklet. PaintWorklet has no communication with the main thread, but AudioWorklet has a MessagePort, which is sometimes used currently by some developers to pass timer information from the main thread.
- The main concern is that this could be a backchannel, causing a privacy and security problem.
- WebPerfWG plans to setup a meeting at TPAC this year to discuss further.
Just wanted to chime in here and say that we'd find this addition incredibly helpful. We're working on a suite of benchmarking tests for audio/DSP load, and having a timer that can give us a higher resolution than 1ms would obviously make the results far more meaningful. For our use case, we'd be fine with a high-resolution timer only being available for cross-origin-isolated sites.
Here are some other use cases I heard from developers:
- Monotonic clock
- Latency metric calculations