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: Adam Goode <agoode@google.com>
Date: Mon, 4 Jun 2012 15:55:14 -0400
Message-ID: <CAOf41Nm-709w0pWRnGDC_SKvmb2D+e8ArU5Ob76zWmr9PTrs0A@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, public-audio@w3.org
The main one I know recently is requestAnimationFrame:
http://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision

On Mon, Jun 4, 2012 at 3:40 PM, Chris Wilson <cwilso@google.com> wrote:
> Has any other spec/feature depended on DOMHRTS - or more particularly, on
> window.performance.now()?  I'm wondering if this is expected/approved/a good
> idea for features like this.  (I'm envisioning that we need a new setTimeout
> too at some point - would it rely on this?)
>
>
> On Mon, Jun 4, 2012 at 12:36 PM, Jussi Kalliokoski
> <jussi.kalliokoski@gmail.com> wrote:
>>
>> 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-
>>>
>>> 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. :)
>>>
>>> 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.
>>>
>>> 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.
>>
>> Cheers,
>> Jussi
>
>
Received on Monday, 4 June 2012 19:55:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 June 2012 19:55:44 GMT