Re: Audio-ISSUE-105 (MIDI timestamp resolution): timestamps in MIDI should use High Resolution Time [MIDI API]

On Mon, Jun 4, 2012 at 6:17 PM, Adam Goode <agoode@google.com> wrote:

> On Mon, Jun 4, 2012 at 1:41 PM, Chris Wilson <cwilso@google.com> wrote:
> > I had some further discussion off-list with Chris, where he helped me
> > coalesce my thinking a little better.
> >
> > I think there are three design factors to a timestamp-
> >
> > What type the actual numerical value is (e.g. WebAudio's currentTime/time
> > params are double, as is DOMHighResTimeStamp - some others are long
> ints, or
> > long longs in Windows).  More importantly for JS devs, though is what the
> > numeric value represents: i.e., number of seconds (in WebAudio) or
> number of
> > milliseconds (DOMHRTS and MIDI proposal).
>
> I think it should be milliseconds, this is consistent with the Date
> constructor which has been around in JavaScript for a long time:
> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date
>
> Extending it to a double makes it easy to increase the resolution
> beyond milliseconds.
>

But Date HAD to be milliseconds, because it's integer.  Anything larger and
it would be (even more) imprecise.


> > What the "zero reference" (or start point) is - e.g. in WA, it's when the
> > audioContext is created, for DOMHRTS in the window.performance.now()
> usage
> > it's navigationStart (although by itself, the DOMHRTS type does not
> imply a
> > "start point" - we need to fix this if we want to use it in the MIDI API,
> > even if it's just to say it's the same as window.performance.now().)  For
> > Date.now(), the zero reference/start point is 1 January 1970 00:00:00
>
> This is an important issue. For MIDI, I see an important use case
> being input to rhythm or other kinds of games. So it should have
> timestamps that can be easily consumed by a game engine. Should this
> be unified with requestAnimationFrame (which is switching to DOMHRTS)?
> Probably, since that seems like a reasonable game engine input. Also
> worth considering are the timestamps used by Gamepad:
> http://www.w3.org/TR/gamepad/#idl-def-Gamepad
> But Gamepad gives no zero-time definition.
>

No - but it makes the point that it explicitly doesn't matter for Gamepad.
 It's really used as an opaque identifier for a given update from hardware,
to see if the system has gotten another update or not.

For timing purposes, I can see times when I'd want to sync my clock with
the audio clock used by Web Audio, but that 1) isn't exposed enough, and 2)
won't always be available.  I guess performance.now() is good enough, if
rAF is going to use it - although I'd wildly prefer a navigator.now() or
something like that.

> On what clock the time proceeds.  This is somewhat subtle, because this is
> > really to account for different clocks possibly running on different
> > crystals - e.g., for WA this is the audio hardware clock. Like
> Data.now(),
> > the performance.now() clock is just the system clock (except it's
> explicitly
> > not supposed to adjust for system time[1]).  But just because you're
> using
> > DOMHRTS type doesn't explicitly mean you're using the system clock -
> > sections 4.3 and 4.4 are specific to the usage in
> window.performance.now(),
> > and the rest of the spec simply defines the type (= #1 above).
>
> Does WA distinguish between DATA and CONTROL? If so, then I see the
> DATA part (audio samples) being driven by the audio hardware's clock,
> but the CONTROL (noteOn, noteOff, etc, and MIDI input/output?)
> controlled by the system clock. But I am newly studying all this
> stuff, so I might be way off here.
>

WA all (audio samples, param ramps, noteOn/Off, etc) runs on the audio
hardware clock.  MIDI i/o typically is not at all related to that clock at
a driver level.  I think we can sync clocks well enough for DAW purposes.

-C