264247 2023-11-06 02:33:21 -0800 getOutputTimestamp() seems to use wrong time scale 2024-02-23 07:59:31 -0800 1 1 1 Unclassified WebKit Web Audio Safari Technology Preview Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 chrisguttandin cdumez cdumez jer.noble webkit-bug-importer youennf oldest_to_newest 1990129 0 chrisguttandin 2023-11-06 02:33:21 -0800 The contextTime returned by getOutputTimestamp() seems to be devided by the sampleRate of the AudioContext. Please take a look at this demo to reproduce the bug: https://stackblitz.com/edit/js-ndbao2?file=index.html,index.js. The contextTime is very small but ends up being a reasonable value when multiplied by the sampleRate. Please also note that the contextTime currently seems to drift away in relation to currentTime. It starts out being smaller than currentTime (as it is in Chrome and Firefox) but soon drifts away until it eventually gets larger than currentTime. 1992068 1 webkit-bug-importer 2023-11-13 02:34:14 -0800 <rdar://problem/118323705> 2016289 2 cdumez 2024-02-22 21:01:42 -0800 ``` diff --git a/Source/WebCore/platform/audio/AudioDestinationResampler.cpp b/Source/WebCore/platform/audio/AudioDestinationResampler.cpp index efd262000a29..257d72887a19 100644 --- a/Source/WebCore/platform/audio/AudioDestinationResampler.cpp +++ b/Source/WebCore/platform/audio/AudioDestinationResampler.cpp @@ -109,7 +109,7 @@ size_t AudioDestinationResampler::pullRendered(size_t numberOfFrames) bool AudioDestinationResampler::render(double sampleTime, MonotonicTime hostTime, size_t framesToRender) { m_outputTimestamp = { - Seconds { sampleTime / sampleRate() }, + Seconds { sampleTime }, hostTime }; // When there is a AudioWorklet, we do rendering on the AudioWorkletThread. ``` Need to write a test case. 2016292 3 cdumez 2024-02-22 21:23:05 -0800 Pull request: https://github.com/WebKit/WebKit/pull/24994 2016384 4 ews-feeder 2024-02-23 07:59:28 -0800 Committed 275237@main (33172dfe163a): <https://commits.webkit.org/275237@main> Reviewed commits have been landed. Closing PR #24994 and removing active labels.