|
|
|
|
|
by flohofwoe
1454 days ago
|
|
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). |
|
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.