On Fri, 26 Mar 2021 17:29:04 +0100, David Henningsson wrote: > > > But actually I'd like to see some measurement how much we can improve > > the timestamp accuracy by shifting the post office. This may show > > interesting numbers. > > Sorry, I don't know the idiom "shifting the post office" and neither > does the urban dictionary, so I have no idea what this means. :-) It was just joking; you basically moved the place to stamp the incoming data from one place (at the delivery center of a sequencer event) to another earlier place (at the irq handler). The question is: how much time difference have you measured by this move? > > Also, one thing to be more considered is the support for MIDI v2 in > > future. I haven't seen any development so far (and no device > > available around), so I cannot comment on this much more, but it'd be > > worth to take a quick look before defining the solid API/ABI. > > I had a quick look at MIDI 2.0. It offers something called "Jitter > reduction timestamps". After some searching I found that its > resolution is 16 bit, and in units of 1/31250 seconds [1]. So the > suggested timestamp format of secs + nsecs would suit us well for that > case, I believe. When implemented, MIDI 2.0 jitter reduction > timestamps would be another clock ID on top of the existing frame > format (or a new frame format, if we prefer). > > A midi 2.0 UMP (Universal Midi Packet) seems to be 4, 8, 12 or 16 > bytes, excluding the timestamp. If we want to fit that format with the > existing patch, we could increase the frame to 32 bytes so we can fit > more data per packet. Do you think we should do that? Otherwise I > think Patch v3 is ready for merging. Let's evaluate a bit what would be the best fit. I see no big reason to rush the merge right now. thanks, Takashi > > // David > > [1] https://imitone.com/discover-midi/ >
