[PATCH v2] sound: rawmidi: Add framing mode

[Takashi Iwai]

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/
>