Bug 17414 - (DOMHighResTimeStamp everywhere): Use DOMHighResTimeStamp for all times?
(DOMHighResTimeStamp everywhere): Use DOMHighResTimeStamp for all times?
Status: CLOSED INVALID
Product: AudioWG - OBSOLETE - Moved to Github
Classification: Unclassified
Component: Web Audio API - OBSOLETE - See Github
unspecified
PC All
: P2 normal
: TBD
Assigned To: This bug has no owner yet - up for the taking
This bug has no owner yet - up for the taking
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-05 12:42 UTC by Michael[tm] Smith
Modified: 2012-09-10 10:10 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael[tm] Smith 2012-06-05 12:42:25 UTC
Audio-ISSUE-106 (DOMHighResTimeStamp everywhere): Use DOMHighResTimeStamp for all times? [Web Audio API]

http://www.w3.org/2011/audio/track/issues/106

Raised by: Adam Goode
On product: Web Audio API

AudioContext.currentTime uses a float type specified in seconds since the creation of the AudioContext.

Is it necessary for each AudioContext to have a unique clock? If not, then it may make sense to use a DOMHighResTimeStamp which is now used by requestAnimationFrame for its timestamps:

http://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision

Having one global high-resolution clock for audio and animation seems to make a lot of sense.


The MIDI draft recently switched to using DOMHighResTimeStamp as well.
Comment 1 Chris Rogers 2012-06-09 00:01:34 UTC
Each AudioContext will have its own clock which normally is based on a specific audio hardware "crystal" and not the system clock.  Thus it cannot be in the same time-coordinate system as the system clock.
Comment 2 Olivier Thereaux 2012-09-10 10:10:11 UTC
No objection to resolution since June, Closing.