Re: [Libusb-win32-devel] Isochronous IN problem

[Travis <lib...@gm...>]

On 11/27/2011 6:03 AM, Ekkehard wrote:
> Xiaofan Chen wrote
>> Travis will be able to give you more details about the limitations of
>> libusb-win32
>> in terms of high speed isochronous transfer.
>>
> Is Travis reading this thread?
>

Yes. I was only away for the holidays. ;)

> Xiaofan Chen wrote
>> One of the motivation to move to libusbK (based on KMDF) is to improve
>> the isochronous transfer.
>>
> Sure, because it's not really working with LibUSB Win32
>
>
> Xiaofan Chen wrote
>> Good to hear that it works for some cases. But for 45Mbit/sec, I think
>> libusbK should able to work. What is the problem you are having?
>> Are you using the libusb-win32 API or the libusbK API?
>>
> For the quick check with libusbK, I simply installed the new generated
> driver, and left my SW unchanged. The major problem is that the data becomes
> corrupted, when the data rate is higher than 10MBit/s.

Your data rate should not be limited in any way by libusbK.  Make sure 
your are using the async API and always have 2 or more transfers pending.
Make sure your test application is not writing gobs of text to std.

Using an AVR UC3 Xplained demo board, We can sustain extremely high data 
rates.

>   With an unchange
> LibUsb-Win32 this occours every time (my minimum data rate is 6-8MBit/s).
> As explained above it is not easy to guess where valid packets are placed by
> the driver in the transfer buffer.

Using these basic transfer functions, libusbK.sys should be packing the 
valid bytes to the front of the transfer buffer.  i.e. When the reap 
function returns the length, indexes 0 thru transferLength-1 contain 
your valid data.  As you have noted, this is not necessarily true  for 
libusb0.sys.  Instead the data remains indexed in packet frames and you 
have no way of knowing which parts of the transfer buffer are valid.

libusb-win32 does transfer splitting in the dll (libusb0.dll).  This 
does not really work for ISO pipes on transfers larger than 64k (hard 
coded) because it waits for each batch to complete before submitting the 
next.  i.e. There must always be multiple pending transfer requests.

> I fill the buffer prior to the query with
> $FF and my packets are clear to identify. But depending on the requested
> size, one specific address becomes damaged.
>
> I am now busy to understand the native libusbK interface. Unfortunally there
> exists no Delphi (Pascal) port, and the header file is huge, so I am
> porting, and porting, ... on a lazy sunday afternoon :-)
>

Yes,  There are C# and vb.net ports but no pascal yet.  At any rate, I 
hope you will send me your codes when your done.  I would like to 
include your pascal port in the distribution packages.
If you run in to problems let me know.  libusbK is in beta so I am still 
able to make public api changes. (not for much longer though)

Reflector can auto-generate delphi code from .NET, but I'm not sure if 
it is any good.
I've attached it, but if you want to use any of it, let me know and I 
will re-generate everything from the most up-to-date libusbK header files.

Regards,
Travis