[PATCH v2] sound: rawmidi: Add framing mode

[David Henningsson]

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