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