Bug 183260

Summary: When Web Audio drops frames, scheduled audioParam changes are off
Product: WebKit Reporter: ae
Component: Web AudioAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: jer.noble, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 11   
Hardware: iPhone / iPad   
OS: iOS 11   

Description ae 2018-03-01 14:01:14 PST
When the CPU can't keep up with filling the audio buffer, scheduled parameter changes (via setTargetAtTime, etc.) "slip into the future" by the length of each missed buffer.
Comment 1 Radar WebKit Bug Importer 2018-03-02 17:04:39 PST
<rdar://problem/38088227>
Comment 2 ae 2018-03-03 08:30:01 PST
OK, I think this may not be a bug after all. As currentTime always seems to reflect the time measured in processed sample buffers, it's obvious that it will drift away from "wall clock time" every time a buffer is missed.

However, the question remains, how can I reliably schedule a parameter change 5 seconds into the future (in WALL CLOCK time)? (Full disclosure: I'm developing an entire DAW using web technologies, and I'm almost done apart from a few web audio roadblocks. When the user hits play, the MIDI data is processed in blocks of 300 ms and for each block, the corresponding AudioParam changes are scheduled for the nodes. As the DAW can run in sync with other (MIDI) equipment, it is essential to queue parameter changes in WALL CLOCK time, NOT audio buffer time. I could of course measure the drift by detecting any offset between (currentWallClockTime - startWallClockTime) and (currentAudioTime - startAudioTime), and then apply that offset to future scheduled events, but I wonder if there's a better way...?