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#5) by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Tue, 02 Apr 2013 19:47:19 GMT

(In reply to [comment #5](#issuecomment-24244090))
> Ehsan, let me clarify the needs here with respect to the latency between the
> context's currentTime and the signal coming out of the sound card.
> 
> High accuracy for this use case is not needed. It's OK for screen updates to
> be slightly delayed for the purposes of seeing a cursor or pointer whose
> position over some sort of waveform or notated music reflects what one is
> hearing. These visual delays will not become really bothersome until they
> are consistently over 75ms or so.  And typically the DOM-to-screen display
> delay is much, much lower (more like the 16ms number you gave).

Right.

> On the other hand these delays can be dwarfed by the
> currentTime-to-sound-card latency on some platforms, which can be as high as
> 200 or 300 ms. Having the cursor be misplaced by that amount is an
> experience-killer. That's why it's so important for an application to be
> able to acquire this number from the API: it's potentially much larger.

Yeah, I totally agree.  But I'm not sure how that related to exposing the potential huge latency to web content.  Ideally an implementation should minimize the latency as much as it can, and bring it well under the ranges that can be perceived by humans.  Once such a latency is achieved, do you agree that exposing the latency information to web content would not be useful any more?

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