Please make high resolution time available within AudioWorkletGlobalScope.

[issuefiler]

The desired feature

High resolution time available within AudioWorkletGlobalScope.

This specification defines an API that provides the time origin, and current time in sub-millisecond resolution, such that it is not subject to system clock skew or adjustments.

---

I’d love to see (self.performance.now() + self.performance.timeOrigin) instead of Date.now() in my processor code, as my process function is called every other third milliseconds at the sample rate of 192000 Hz.

---

Note

Currently there’s no way for my processor to use it.

DOMException: Failed to execute 'postMessage' on 'MessagePort': Performance object could not be cloned.

[kawogi]

Additionally: new Date() is an allocation (unless optimized out) which should not be done in a Worklet.
Misread the code, sorry.

[padenot]

This makes sense. We need to look at the performance object to see if we want everything in it (probably not).

[issuefiler]

@guest271314

……dedicated MessagePort can be created specifically to post result of performance.now() to AudioWorkletGlobalScope

We could do that, but messaging with each other takes extra time. It is the process function in an AudioWorkletGlobalScope that knows the most accurate timing to stamp the time on samples.

[issuefiler]

Right. For my personal use case, I need to know (more) exactly what time the processed samples correspond to, and it turned out just performance.now() available would not be enough for that as the samples are buffered to be processed. We could look for something that’ll provide detailed and reliable information about the timings and more.

[padenot]

Virtual F2F:

• This is desirable for the reasons explained at https://github.com/WebAudio/web-audio-api-v2/issues/40#issuecomment-642695649

[padenot]

TPAC 2020:

• Precise timers are still problematic because they allow side channels still. It might be possible to hide this behind COOP/COEP.
• Real performance profiling tools (real-time safe) are now available and are bound to be equal or better than what can be done by authors. This was not the case when the comment above was made.
• A view of load from the control thread is still desirable (Add detail of connecting audio node to non audio node #40), because having performance.now() doesn't allow measuring native nodes.

[padenot]

Precise timers are still problematic because they allow side channels still. It might be possible to hide this behind COOP/COEP.

This is what w3c/hr-time#89 is about, it seems possible. hr-time should offer a hook that says "if this document is isolated, timers are precise".

[brutzman]

If repeatably feasible, use of high-resolution time values will likely be valuable for X3D Graphics use of Web Audio API for presentation of acoustics. (This is speculative, potential future use case.)

[rtoy]

Teleconf: It seems the primary use case (not including https://github.com/WebAudio/web-audio-api-v2/issues/77#issuecomment-796910897), is for performance evaluation. Perhaps this is covered in WebAudio/web-audio-api-v2#40, in which case there may not be a need for this in a worklet.

Leave this open, but reduce priority, pending more use cases that aren't related to performance measurements.

[rtoy]

See also https://www.w3.org/TR/hr-time-3/#the-performance-attribute

[padenot]

AudioWG virtual F2F:

• This is being requested by lots of people, we need to do it

[hoch]

@juj also asked this in #2527. I think we should get the spec change first since the actual spec work might be very small.

[Night12138]

Hi everyone, how is the progress going? We need to know the current render capacity, and a high-precision clock is required.

[hoch]

2023 TPAC Audio WG Discussion:
Because this involves the high resolution timer on a high priority thread, each implementer will first have an internal security discussion. The discussion will continue once the implementers are confident in changing the spec and beginning implementation.

[juj]

I thought the process isolation mechanism addressed high precision timer security issues?

In any case, it is possible today to create a high precision timer by creating an AudioWorklet with a SharedArrayBuffer, in an AudioContext with sampling rate of 192000, and in the process function, just ++ an integer in the SAB. That gives you a somewhat precise 0.666msec granular timer, and that can be used to polyfill performance.now() in absence of the real thing. Exposing performance.now() today would be weaker than that.

The need to get performance.now() into AudioWorklets at least for the Emscripten community is of ergonomy, so that we don't need to create polyfills in different scopes so that wasm compiled code can run in all threads the same.

[padenot]

Because this involves the high resolution timer on a high priority thread, each implementer will first have an internal security discussion. The discussion will continue once the implementers are confident in changing the spec and beginning implementation.

With my Firefox implementer hat on, and after talking internally:

In Firefox, iff if the page is able to instantiate SharedArrayBuffer (e.g. because the headers have been set when loading the document), then the precision of performance.now() is 20us, which might well be good enough for our purpose here.

[hoch]

@padenot What would be the next step to make this possible? It looks like a great addition that is reasonably popular.

[sbc100]

This issue came up again recently on the emscripten side: emscripten-core/emscripten#22962.