NEW 183260
When Web Audio drops frames, scheduled audioParam changes are off 
https://bugs.webkit.org/show_bug.cgi?id=183260
Summary When Web Audio drops frames, scheduled audioParam changes are off
ae
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2018-03-02 17:04:39 PST
<rdar://problem/38088227>
ae
Comment 2 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...?
Note You need to log in before you can comment on or make changes to this bug.