On Mon, Sep 07, 2009 at 09:03:05PM +0000, Michael Lotz wrote: > > > Are you saying, though, that I can build that buffer essentially as > > large > > as I like, distinct from the 'maximum packet size' (64 bytes) of the > > device > > hardware itself? > > Yes that's exactly what I am saying. Feel free to pack as much data > into a buffer as you want (there's a certain limit, but you're unlikely > to hit that). If the device sends more than one MIDI packet per > incoming USB transfer, then I guess it will be fine if you do the same > and pack more than one MIDI packet into the outgoing transfer as well. > The packet size used for incoming transfers is really device specific. > Some will send large buffers, some will limit them to the max packet > size, some something completely different... If you scheduled the > incoming transfer with a size of 64 bytes only, this would at least > explain why you never got more than that at a time. Great! That will simplify the code quite a bit. > > Why do large SysEx packets need to always be split? I cannot speak for > the MIDI side of things, but from a purely USB standpoint of view this > is not necessary. If the MIDI packets you are using have a limit there > then that's something different of course, I wouldn't know. I was thinking from a purely practical viewpoint. As the buffer to be sent to the USB side has to be built (and is bigger than the original data), it really has to be a preallocated fixed size -- don't want to malloc each time... And presumably in any case the data passed by the midi_server doesn't stick around, so I have to copy it to queue it (or else stall the write function until the callback). Only really big (and uncommon) SysExs would have to be split, but I don't think one could rely on a maximum. > Many thanks for the illumination. I should get back to recoding later today... Cheers, -- Pete --