Re: [web-audio-api] Need a way to determine AudioContext time of currently audible signal (#12)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=20698#22) by Joe Berkovitz / NF on W3C Bugzilla. Thu, 25 Apr 2013 17:18:30 GMT

Capturing discussion from the WG conference call 4/25/2013:

- Need to document that currentTime represents the time at which the next sample block to be synthesized by the node graph will be played.

- Need to document that currentTime advances (for an non-offline context) roughly in real time, not just monotonically.  In other words, the clock-time derivative of currentTime is approximately 1.

- Will introduce a new read-only attribute on AudioContext that exposes a "presentation latency" as described in the initial comment for this bug. This latency is not an absolute guarantee, it just includes all predictable latency contributions known to the implementation. On Android <= 4.0, for instance, this latency would expose the roughly .25 second delay imposed by the platform.

- AC will expose a function converting from currentTime units to high-resolution DOM performance time.

- AC will expose an inverse function converting from high-resolution DOM performance to currentTime units.

An additional note that was not discussed:

- Corollary: need to document (if this is true) that currentTime advances monotonically by a time quantum equal to the block size, as each block is synthesized.  This is important because if true it implies that ScriptProcessingNode JS code may consult currentTime instead of event.playbackTime, and that the latter is no longer needed since it's always equal to currentTime.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/12#issuecomment-24244188