Hi, On Wed, Mar 24, 2021 at 12:18:59PM +0100, David Henningsson wrote: > On 2021-03-24 11:03, Takashi Iwai wrote: > > This looks like a good middle ground solution, while we still need to > > address the sequencer timestamp (basically we should be able to send > > an event with the timestamp prepared from the rawmidi side). > > I believe the new framing mode would be useful both for readers of rawmidi > devices, and the seq kernel module. > > I have also been thinking of doing something in usb-midi (because I assume > that's the most common way to do midi input these days), to improve > performance for packets with more than three bytes in them. Right now a > sysex would be cut off in chunks of three bytes, each one with its own > timestamp. If so, that would be a later patch. I've been investigated with some old documentations since David posted his initial idea[1]. However, I always have concern that we can really find timestamp for incoming data for MIDI message in hardware/software IRQ contexts. As you know, in the specification, MIDI message has no timestamp. Even if MIDI Time Code (MTC) is included in the specification, it's the role for hardware MIDI sequencer to decide actual presentation time for received MIDI messages. In this meaning, your patch is reasonable to process the received MIDI messages. However, the timing jitter of IRQ handler invocation is issued in this case, as well as PCM interface, even if the data rate of MIDI physical layer is quite low nowadays (31.25 Kbit / sec ~= 3906.25 byte / sec). As long as I experienced, in actual running Linux system, the invocation of IRQ handler has no guarantee for timing jitter, mainly due to CPU level IRQ mask (like spin_lock). Therefore the interval of each invocation is not so precise to decide event timestamp, at least for time slot comes from MIDI physical layer. Nevertheless, I think your idea is enough interesting, with conditions to deliver information from driver (or driver developer) to applications (ALSA Sequencer or userspace applications). Even if we have some limitation and restriction to precise timestamp, it's worth to work for it. It seems to be required that improvements at interface level and documentation about how to use the frame timestamp you implemented. P.S. As long as referring old resources relevant to the design of hardware MIDI sequencer in late 1990's, the above concern seems to be real to engineers. They are always requested to process MIDI message in real time somehow beyond buffering and timing jitter. [1] Midi timestamps https://mailman.alsa-project.org/pipermail/alsa-devel/2021-March/182175.html Regards Takashi Sakamoto
