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.
<rdar://problem/38088227>
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...?