[iostream24]

This is somewhat insane. WHY is no one looking at how protocols explicitly invented to solve this problem work?

PTP precision time protocol, albeit implemented on the wrong layer to be directly useful here, solves it by timestamping frames.

[radiowave]

It's not clear to me that any of the challenges the article addresses could be improved by the use of a clock synchronization protocol, such as PTP - it is not within the gift of application software to modify the audio sample rate clock, nor the display refresh rate.

Beyond what the article discusses, I can imagine long-running audio applications where it might be useful to build an estimate of the rate at which the system time drifts relative to the sample rate clock. Even so, we're still in the realm of the application software having to take these slightly divergent timing sources as given.

[kierank]

Or just have a way for a chipset to expose it's clock instead of all the methods people use to guess using buffer fullness.

[tomduncalf]

Isn’t timestamping frames (events) essentially what osc.start/stop (in this example) is doing, by allowing you to pass a timestamp in the future for an event which will then be internally scheduled on the audio thread?

The issue really is that all your code is running on the UI thread with JavaScript, so you can’t accurately time stuff, whereas in C++ you’d write this stuff to execute on the audio thread callback. That said, this is now possible with AudioWorklets - but I don’t think you could interact in a sample accurate way with browser-supplied WebAudio nodes from there, so ultimately you still end up needing to schedule them for a future time if accuracy matters.

[flohofwoe]

This would be way overengineered, all that's needed is a local monotonic time source with a good enough precision of somewhere between 1 to 10 microseconds. There's no need to synchronize the time with other sources, unless the goal is to control peripheral devices (which is out of scope for WebAudio anyway).

The other problem of (traditional) WebAudio is that all work needs to happen on the browser thread which runs in time slices at a very low frequency (usually 60Hz or the display refresh rate).

There's now a solution called audio worklets, but those aren't exactly trivial to work with unless all work can happen in the worklet thread (for instance you need to write your own ring buffer to push commands or sample data from the browser to the audio thread).

[eqvinox]

> There's no need to synchronize the time with other sources,

The problem isn't synchronicity, it's syntonicity, albeit only to a limited degree. What you need to know is: how much is your local audio sample clock off from the source audio clock, and from your (distinct) video output clock.

But microseconds precision is indeed perfectly fine, ideally with some way to get simultaneous timestamps from the different clocks at least for the local clocks.

I don't see PTP playing into this either, if anything the associated hardware timestamping features might be a "nice to have to make it perfect", but noone I know wires the audio clock into the PTP timestamping unit.

[kierank]

No consumer chipsets that I know of allowing drifting the clock to match an external clock source so PTP is a non starter. And I've not seen many pro sound cards with drifting support either.