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