[Bug 20698] Need way to determine "performance.now()" time of current audio output

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20698

--- Comment #6 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to comment #5)
> 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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 2 April 2013 19:47:22 UTC