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

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

@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.

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.

Virtual F2F:

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

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.

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".

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.)

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.

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

AudioWG virtual F2F:

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

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

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

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.

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.

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.

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

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

We now have a Chromium issue that is asking for this and also said that Microsoft Edge has already gone ahead and implemented the Performance API in worklets.

It seems like there is support for this overall so we should probably spec it out soon. I'll add it to the agenda for next WG meeting.

To follow-up to what @mjwilson-google says, this would need to happen here: https://w3c.github.io/hr-time/#sec-performance

Just a PR that adds , AudioWorklet, after in the Exposed section.

I tried to check if this is really implemeted in Edge. I ran my test in version 132.0.2957.140 on macOS. This is the code that I used.

class TestProcessor extends AudioWorkletProcessor {
    constructor () {
        super();

        console.log(typeof performance);
    }

    process() {
        console.log(typeof performance);

        return true;
    }
}

console.log(typeof performance);

registerProcessor('test-processor', TestProcessor);

It logged 'undefined' all the time. Maybe I'm testing for the wrong thing but it looks like the Performance API isn't available in Edge either.

@chrisguttandin did you try to run this in isolated mode as well?

Even if it's not actually supported in Edge yet we should still do this. Maybe I misunderstood the issue report.

this would need to happen here: https://w3c.github.io/hr-time/#sec-performance

So it's actually outside our spec? I can raise the PR if we're all in agreement.

So it's actually outside our spec? I can raise the PR if we're all in agreement.

Yes, this spec I linked defines where their stuff is exposed, but we're the one that can ask for it to be exposed, if that makes sense.

@chrisguttandin did you try to run this in isolated mode as well?

@padenot I set the COEP/COOP header pair and also made sure that SharedArrayBuffer is available.

we're the one that can ask for it to be exposed, if that makes sense.

Makes sense to me! I raised w3c/hr-time#169 -- please add supporting comments there if necessary.