W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

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

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Mon, 4 Jun 2012 22:36:20 +0300
Message-ID: <CAJhzemUvDoGmOA3GK37=K3sYgL1kkk536FBWTEyUcd0GVof5iw@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: Adam Goode <agoode@google.com>, public-audio@w3.org
On Mon, Jun 4, 2012 at 8: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-
>    1. 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'd go for milliseconds as that's consistent with everything else on the
web (Date.now(), setInterval, setTimeout, DOMHRTS). As to what the type of
the number is, I'd say preferably a double (or more precise), but
implementations can have different underlying optimizations and I don't see
a need (nor do I think it's even possible) to impose further limitations on
that. If the end developer needs just pure milliseconds and the decimal
part will make his life harder, I hope they'll use a language that allows
you to floor numbers, heh. :)

>    1. 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 UTC.
>    1. 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).
For consistency, I'd go with the navigationStart, i.e.
window.performance.now(), we should avoid respecifying things that other
groups have already specified, such as clocks. As for audio/midi clock
synchronization, I think it isn't anything that needs to be visible to the
end developer, the implementations should just synchronize with these
internally, imho.

> For the purposes of the MIDI API, I don't have any real problem with using
> the DOMHRTS type - but I'm a) not really psyched about having to use
> window.performance.now() in a MIDI application to get the zero-reference,
> because it seems like that is really designed to be a performance-timing
> thing, and b) a little less pleased that Web Audio times are in seconds,
> and this timestamp would be in milliseconds.  Neither of those are
> completely disastrous, but they both seem less than optimal.  Anyone else
> have thoughts on that?  Any thoughts about how developers usually think?

Personally I think it's a bit confusing that Web Audio API uses seconds
instead of milliseconds, because like I said, most time related values on
the web are presented as milliseconds.

Received on Monday, 4 June 2012 19:36:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:59 UTC