Andreas Steinmetz wrote: > On Mon, 2020-03-16 at 13:03 +0100, Clemens Ladisch wrote: >> Andreas Steinmetz wrote: >>> the snd_usbmidi_transmit_byte helper had to be converted to >>> return output notification to allow for the 'repeat' shortcut. >> >> Why not simply handle one MIDI byte per port in each iteration? It >> could be argued that single-byte MIDI commands are likely to be real- >> time messages and deserve to go first. > > Actually the patch does exactly this. As soon as the helper signals > that a message is complete the next port is processed. The "repeat" > loop is just necessary to get a complete class compliant message for > transfer as the helper processes one byte at a time. Why is it necessary to immedately get a complete class-compliant message? > The range optimization is there to prevent O(2) performance cost if > possible. Do you mean O(n^2)? For what n? >> My original idea for that FIXME was to use round robin until the packet >> is filled (or all ports are empty), and to store the next port index >> (where to start for the next packet) in the endpoint. This would be >> able to distribute the balancing over multiple packets. > > The problem with "round robin until the packet is filled" is that in > case of a large wMaxPacketSize there's then a huge latency. This mechanism does not require using the original packet size. The point is that we should not restart with the first port in each packet. Regards, Clemens
