[PATCH 0/3] ALSA USB MIDI: Predictable low latency for USB MIDI output

[Takashi Iwai]

On Sat, 14 Mar 2020 09:11:17 +0100,
Andreas Steinmetz wrote:
> 
> The following patch series fixes USB MIDI output starvation and allows
> to configure a predictable worst case output latency with a minimum of 15ms
> for 16x16 devices and 3.8ms for 4x4 devices (excluding USB transfer time
> and latencies of the interface device itself).
> 
> The reasoning behind this patch series is first to fix the possible
> indefinite latency and then to allow to configure a predictable
> low latency to be able to use a cheap embedded Linux system (e.g.
> Raspberry Pi) in combination with a multiport USB MIDI interface
> as a drop in replacement for commercial hardware based MIDI routing
> and filtering products. This includes "real time" (live) usage.
> 
> For this usage the guaranteed latency within the kernel must be as
> low as possible, depending on the requirements of the USB MIDI
> interface in use.
> 
> Though the current state of the kernel code is acceptable in a
> fully controlled by a single user environment, it is not usable
> for uncontrolled standalone use as the driver behaviour then
> depends on unpredictable MIDI data streams and thus is unpredictable
> in behaviour itself.
> 
> After applying this patch series the USB MIDI driver can be used
> as usual or it can be tuned to low latency when this is desired.
> 
> >From a developer perspective the actual output rate of USB MIDI
> interfaces is typically slower than the expected 320us and even
> varies depending on how many ports are busy (e.g. a M-Audio
> Midisport 4x4 AE interface exhibits a varying output rate of
> 357us to 515us per byte depending on device load). Thus the driver
> needs a predictable low latency to allow userspace to use the
> rawmidi buffer fill state to estimate the expected output latency
> and schedule data accordingly.
> 
> The following table shows relative processing time for varying driver
> configurations using the M-Audio Midisport 4x4 AE as the test device.
> For the parameters "outqueue" and "events" do see the descriptions
> of the following patches.
> 
> 	| unpatched	| outqueue=7	| outqueue=1	| outqueue=1	|
> 	| kernel	| events=0	| events=0	| events=4	|
> --------+---------------+---------------+---------------+---------------+
> 1 Port	|      100%	|      100%	|      100%	|    100.05%	|
> --------+---------------+---------------+---------------+---------------+
> 4 Ports	|      n/a	|      100%	|     99.97%	|    100.36%	|
> --------+---------------+---------------+---------------+---------------+
> 
> As can be seen from the above table the changes to output latency do
> affect throughput only marginally.

Thanks for the patches and the analysis.

So, judging from the experiments above, outqueue=1 has no measurable
performance regression?  For 4 ports, it's even an improvement.
Then we may change the default value.

I guess you kept the old value just to be conservative, but if the
number tells a better story and it's no part or ABI, we may consider
changing the default for a better performance.

Or, is there any other potential risk by changing this?


thanks,

Takashi