It can anywhere between 100ms and 20 micro seconds.
It all depends on the browser.
AudioContext.currentTime returns a double representing an ever-increasing hardware timestamp in seconds with a certain precision that can be used for scheduling audio playback, visualizing timelines, etc.
AudioBuffer can be started at the particular time.
AudioBufferSourceNode.start([when][, offset][, duration])
For one example, a seamless two-buffer playback.
AudioBuffer1 will start when AudioBuffer0 is done. Hopfully, this will play continuously without hick-up between buffer0 to buffer1 transition. And when AudioBuffer0.onended event fires, queue another AudioBuffer0 with the start time set to the end time of AudioBuffer1. At AudioBuffer1.onended event, queue another AudioBuffer1 with start time of the end of AudioBuffer0. By switching between these two buffers, it should play smoothly and continuously as if it is one longer buffer.
Not sure if this really will work as expected. To be determined later by actually coding to this spec.
The real test result: there are audible hick-ups. It does not work. :-0
createScriptProcessor is last hope.