Xiaofan Chen wrote:
> For isochronous OUT request, since the host know (at least it
> should know) the size of each packet, so this is not an issue, right?
Yes.
>> So, if your device skips one interval, you will have a gap in your
>> buffer. If your device sends short data in one interval, again you will
>> have a gap in your buffer.
> How does the host program deal with this kind of gap in the buffer?
The host program has to reconstitute it. If you need a packed buffer
(as most programs do), you end up with a loop like this:
buffer pointer = 0
for( each packet )
if( there is data in this packet )
copy packet length bytes to buffer pointer
buffer pointer += packet length
> So it is clear that the host program should use multiple of the
> isochronous IN endpoint max packet size as the read buffer.
>
> But isn't it the same for interrupt transfer or bulk IN transfer in the
> case you do not know the expected data the device will send?
> In that case, you will have to use multiple of the IN endpoint
> max packet size as the read buffer.
You are absolutely correct. *Every* IN request, regardless of pipe
type, should always be a multiple of the maximum packet size.
> Right? On the occasion
> that you know exactly how many data to expect, then of course it
> is okay to use the that.
Yes, assuming everything always goes as planned... It doesn't cost
anything to round your buffer sizes up in EVERY case.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
