On 2021-03-31 09:40, Takashi Iwai wrote:
On Tue, 30 Mar 2021 21:35:11 +0200, David Henningsson wrote:
Well, I believe that rawmidi provides less jitter than seq is not a theoretical problem but a known fact (see e g [1]), so I haven't tried to "prove" it myself. And I cannot read your mind well enough to know what you would consider a sufficient proof - are you expecting to see differences on a default or RT kernel, on a Threadripper or a Beaglebone, idle system or while running RT torture tests? Etc.
There is certainly difference, and it might be interesting to see the dependency on the hardware or on the configuration. But, again, my primary question is: have you measured how *your patch* really provides the improvement? If yes, please show the numbers in the patch description.
As you requested, I have now performed such testing.
Results:
Seq - idle: 5.0 ms
Seq - hackbench: 1.3 s (yes, above one second)
Raw + framing - idle: 2.8 ms
Raw + framing - hackbench: 2.8 ms
Setup / test description:
I had an external midi sequencer connected through USB. The system under test was a Celeron N3150 with internal graphics. The sequencer was set to generate note on/note off commands exactly 10 times per second.
For the seq tests I used "arecordmidi" and analyzed the delta values of resulting midi file. For the raw + framing tests I used a home-made application to write a midi file. The monotonic clock option was used to rule out differences between monotonic and monotonic_raw. The result shown above is the maximum amount of delta value, converted to milliseconds, minus the expected 100 ms between notes. Each test was run for a minute or two.
For the "idle" test, the machine was idle (running a normal desktop), and for the "hackbench" test, "chrt -r 10 hackbench" was run a few times in parallel with the midi recording application (which was run with "chrt -r 15").
I also tried a few other stress tests but hackbench was the one that stood out as totally destroying the timestamps of seq midi. (E g, running "rt-migrate-test" in parallel with "arecordmidi" gave a max jitter value of 13 ms.)
Conclusion:
I still believe the proposed raw + framing mode is a valuable improvement in the normal/idle case, but even more so because it is more stable in stressed conditions. Do you agree?
If so, I'll send out a v4 with 32 byte framing (16 byte header, 16 byte data).
// David