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

Gah!  yes, sorry, didn't hit reply-all. Only thing in Gmail I'm still not
quite used to, somehow.

Yes, I agree that it's not great to have so many different timestamp
formats and reference points.  If the desire is to divorce from wallclock
time, then I supposed we could do like audioContext does - from when
MIDIAccess is created.  As written in Jussi's last edit, though, it's
"current time" (unfortunately, the definition of what that means (ms since
UNIX epoch) was removed).  I don't have strong feelings.  I mostly disliked
DOMHighResTimeStamp because it's one more reference, for what is
essentially a trivial thing (monotonically increasing, number of
milliseconds, unrelated to wallclock time), but that spec is really defined
for uses relating to Performance, so it's confusing to read as a solution
for this problem.  I think we would need to define our own zero point.

I like seconds just because I think if it's not integer anyway, it's easier
for humans to think that way, but I don't care that strongly.  The newer
MIDI interfaces in Windows, I note, use a longlong (64bit int) of units of
100ns (i.e. tenths of a microsecond, or 0.0001 milliseconds).  I think that
is kind of confusing, personally.  Seconds are prevalent in the Web Audio
API, but milliseconds (as ints) are common in other web programming APIs,
so I could be okay with either.

On Fri, Jun 1, 2012 at 12:17 PM, Adam Goode <agoode@google.com> wrote:

> On Fri Jun 01 13:53:52 GMT-400 2012, Chris Wilson <cwilso@google.com>
> wrote:
>
>> Well there you go - it's been quite a while since I wrote Windows code.
>>  :)
>>
>> >The point of DOMHighResTimeStamp is that it is divorced from
>> wallclock time.
>>
>> So is audioContext.currentTime.
>>
>>
> Hmmm. It's not great to have so many different timestamp formats and
> reference points. It does make sense for audioContext to have its 0 point
> at its start time. And there is no "start time" for these raw MIDI events.
> So deferring to page load time seems fine.
>
> But the units are different (seconds in float vs. milliseconds in double),
> and that seems worth addressing.
>
>
> (Did we drop off the public list with this thread?)
>
> Adam
>
> On Fri, Jun 1, 2012 at 10:49 AM, Adam Goode <agoode@google.com> wrote:
>>
>> On Fri, Jun 1, 2012 at 12:47 PM, Chris Wilson <cwilso@google.com> wrote:
>> >
>> > Although I'm not completely opposed to this change, I'd argue against
>> the point that millisecond resolution is insufficient.  If using hardware
>> MIDI ports, it takes approximately 1/4 of a millisecond to SEND a single
>> byte of data - so it will take approximately 3/4 of a millisecond to simply
>> transfer the data anyway - and the latency in processing at the other end
>> is typically much, much higher than 1ms (I seem to recall around 4-7ms was
>> not atypical for hardware synths, but can't find my reference ATM).
>> >
>>
>> The issue is more of jitter, not of processing delay. Though 1ms seems
>> totally sufficient to me, I could imagine issues with the single byte
>> timing code (F8) getting some unwanted jitter. But the real win of
>> this change is monotonicity.
>>
>> >
>> > That said, of course, it's not a bad idea to future-proof better than
>> that; many MIDI use cases will never actually see a 5-pin-DIN cable.
>>  However,
>> >
>> > 1) I find the usage of DOMHighResTimeStamp very confusing, as it's
>> deliberately chained to (in terms of "zero" point) to the Performance
>> interface.  It doesn't seem to add any value to reference here, since it's
>> simply a double; we would still need to provide a way to get system time in
>> double units, as I don't think using the PerformanceTiming interface is the
>> most intuitive thing to do.  Or suggest that people use Date.now() (even
>> though it's millisecond-precision), which is livable, I suppose.  But we do
>> need to define that.  I would recommend either a) using a double for number
>> of milliseconds, and recommending people use Date.now, or b) (my
>> preference) use a double to represent number of seconds, to be uniform with
>> the Web Audio API.  I'm ambivalent about whether we use the same
>> currentTime from the audioContext as WA or Date.now().
>> >
>>
>> The point of DOMHighResTimeStamp is that it is divorced from wallclock
>> time. All the MIDI implementations use this kind of time stamp (even
>> Windows, read on).
>>
>>
>> >
>> > 2) I would absolutely recommend that we (similar to
>> DOMHighResTimeStamp) explicitly state that implementations are allowed to
>> have millisecond-only precision in their implementation.  The underlying
>> system APIs on Windows are based in milliseconds, for example - unless
>> they're building another API, the time stamps on MIM_DATA are in
>> milliseconds. The underlying API on OSX is a bit harder to determine
>> precision, but I think it is higher.
>> >
>>
>> Actually the ONLY part of DirectMusic that is undeprecated (it
>> disappeared briefly in Vista, then was replaced in a service pack) is
>> high resolution monotonic MIDI timestamps:
>>
>> http://msdn.microsoft.com/en-us/library/ee416788(VS.85).aspx#ID4EFEAC
>> http://support.microsoft.com/kb/943253
>>
>>
>> So yes, we can specify that the timestamps might only have ms
>> resolution, but I don't think it's really required.
>>
>>
>> Adam
>>
>> >
>> >
>> >
>> > On Fri, Jun 1, 2012 at 8:48 AM, Jussi Kalliokoski <
>> jussi.kalliokoski@gmail.com> wrote:
>> >>
>> >> This issue is now pending review per
>> https://dvcs.w3.org/hg/audio/rev/b78b7c5e906e .
>> >>
>> >>
>> >> On Fri, Jun 1, 2012 at 6:22 PM, Jussi Kalliokoski <
>> jussi.kalliokoski@gmail.com> wrote:
>> >>>
>> >>> Good catch, thank you! As I planned it, the timestamp should have
>> been a floating point value, allowing for sub-millisecond precision, but
>> actually DOMHighResTimeStamp is actually more fit fore this.
>> >>> I will make the necessary changes to the spec.
>> >>>
>> >>> Cheers,
>> >>> Jussi
>> >>>
>> >>>
>> >>> On Fri, Jun 1, 2012 at 6:16 PM, Audio Working Group Issue Tracker <
>> sysbot+tracker@w3.org> wrote:
>> >>>>
>> >>>> Audio-ISSUE-105 (MIDI timestamp resolution): timestamps in MIDI
>> should use High Resolution Time [MIDI API]
>> >>>>
>> >>>> http://www.w3.org/2011/audio/track/issues/105
>> >>>>
>> >>>> Raised by: Adam Goode
>> >>>> On product: MIDI API
>> >>>>
>> >>>> The current MIDI API specifies timestamp as a long representing
>> "milliseconds from the UNIX Epoch".
>> >>>>
>> >>>> For MIDI applications, millisecond resolution is insufficient and
>> can cause noticeable jitter.
>> >>>>
>> >>>> Using absolute wallclock time is also problematic, as it is subject
>> to system clock skew.
>> >>>>
>> >>>> The MIDI timestamp should use High Resolution Time
>> (DOMHighResTimeStamp), which solves these problems:
>> >>>>
>> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>>
>>