[haiku-development] Re: Am I misunderstanding USB queue_bulk?
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 7 Sep 2009 14:49:42 -0700
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 --
Other related posts:
