change: Expose Performance interface to AudioWorklet

[mjwilson-google]

Closes WebAudio/web-audio-api#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)
• Chromium
• Gecko (positive based on issue comments and meeting)

---

Preview | Diff

[yoavweiss]

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

[mjwilson-google]

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?

[yoavweiss]

We can discuss this on the next call, on August 28th 10am PT. Would that work for you?

[mjwilson-google]

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?

[yoavweiss]

Added you to the invite. You can just join :)

[mjwilson-google]

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.

[jas-ableton]

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.

[mjwilson-google]

Here are some other use cases I heard from developers:

• Monotonic clock
• Latency metric calculations

[mjwilson-google]

During TPAC 2025 we came to the following conclusions:

• This PR should be changed to just expose the performance.now method, not the entire interface
• We will also need to pipe the cross-origin isolation bit and set the time origin, both of which are straightforward
• As far as the spec goes, there are no particular privacy or security concerns

Next step is for me to revise this PR as above, then we can iterate if necessary.

[padenot]

@mjwilson-google did you get a chance to look at this again? We're ready to ship this in Firefox, but won't do so before the spec is merged and clear.

[mjwilson-google]

No, I haven't had a chance to revise the PR yet. From discussion at TPAC it should be straightforward (that is, there are no blockers that I know of), I have just been focused on other things.