Re: LibUsbK Isochronous Write C# example
Stephen B <[email protected]> Wed, 22 Oct 2014 22:19:31 +0200
| Newsgroups | gmane.comp.lib.libusb.devel.windows |
|---|---|
| Message-ID | <CAKPi28qhJej63MVfcxEJtuBCenKmugqQ=2NCmVQVWZ3syi_82A@mail.gmail.com> |
Hello,
Thanks a lot, I'm making progress...
I've set the pipe policy to false:
>int[] pipePolicyStartAsap = new[] { 0 };
>bool success = usb.SetPipePolicy(0x06,
(int)PipePolicyType.ISO_ALWAYS_START_ASAP, 1, pipePolicyStartAsap);
Then I retrieve the current frame number using:
>int currentFrameNumber = 0;
>usb.GetCurrentFrameNumber(out currentFrameNumber);
>int totalFramesAdded = 0;
>int addFrames = 16;
addFrames is a constant; the difference between each frame. I raise
totalFramesAdded with addFrames before each IsoWritePipe call and also
while declaring the 5 IsoContexts:
>totalFramesAdded += addFrames;
I'm now using multiple IsoContexts, thanks for pointing that out. I declare
them like this:
>Iso1 = new IsoK(64, currentFrameNumber + totalFramesAdded);
With USBPcap I have now noticed each transfer has a transfer start frame!
This field was always 0 before. Each new frame starts 8 frames later,
probably because I was sending 8192 bytes per transfer. To make things a
little easier I have reduced the number of packets per transfer from 64 to
8, so I send only 1024 bytes instead of 8192 bytes. Now the transfers send
every frame.
However, this is still not what it should be doing yet. No matter what
value I use for addFrames, the transfers are always being sent each frame.
This is my latest code, cleaned up a bit: http://pastebin.com/zQHp3GAE (5
buffers, 1024 byte transfers = 8 packets of 128, transfers *should* be sent
each 16 frames).
I must be overlooking something... I hope I can stop bothering you soon ;)
Thanks a lot so far!
Kind regards,
Stephen
2014-10-22 17:25 GMT+02:00 Travis <[email protected]>:
> Greetings,
>
> Yes, I think I understand the problem. You can use the polling interval
> in the endpoint descriptor to change the transfer rate as well.
>
> I have "C" example code for setting the start frame but here is the just
> of it.
> 1) Start by setting the 'ISO_ALWAYS_START_ASAP' pipe policy to false.
> 2) Use UsbK_GetCurrentFrameNumber() to determine what the frame count is
> currently set to
> 3) Update IsoContext.StartFrame before submitting each transfer with
> your modified value.
>
> One problem I see in your code is you have not created an IsoContext for
> each transfer. You need an IsoContext for each aync transfer operation.
> IE: For every overlapped handle, you need an IsoContext.
>
> Regards,
> Travis
>
> On 10/20/2014 3:07 PM, Stephen B wrote:
> > Hello,
> >
> > I think I understand the concept of ISO pipes, and also that the data
> > stream should be continuous. This is what I'm having problems with;
> > scheduling new write transfers one after another, with some time in
> > between (the time it takes for a full transfer of data to be "used
> > up"/emptied by the device).
> > From this article
> > (
> http://msdn.microsoft.com/en-us/library/windows/hardware/dn376866(v=vs.85).aspx
> > <
> http://msdn.microsoft.com/en-us/library/windows/hardware/dn376866%28v=vs.85%29.aspx
> >)
> > I understand that I need to set the StartFrame for each transfer, with
> > a small offset between each, so the transfers won't be sent instantly.
> > This does not interrupt the stream of data because the device needs
> > time to process the packets of the transfer.
> >
> > But I don't know how to set the startframe for each subsequent
> > transfer... This is a summary of my code (I use 5 buffers now, but
> > that doesn't matter): http://pastebin.com/29GZmswb
> > The only related piece of code I know of is the 0 in "Iso = new
> > IsoK(64, 0)", but I don't understand how to set the StartFrame for the
> > next transfers. I think something isn't right with my code structure.
> >
> > When I run this, I get the following results when I capture the
> > transfers with USBPcap (5 buffers used while capturing this):
> > http://imgur.com/USTj9g2
> > You can notice the transfers are spamming my device (even my
> > hard-drive is getting really noisy while capturing these transfers).
> >
> > Thank you once again in advance for your help. I hope I don't have a
> > complete misunderstanding of the ISO concept, and I also hope that I
> > have clarified the issue better now.
> >
> > Kind regards,
> > Stephen
> >
> > 2014-10-14 21:18 GMT+02:00 Travis <[email protected]
> > <mailto:[email protected]>>:
> >
> > Greetings,
> >
> > I'm not sure which part to clarify here.
> >
> > ISO pipes have a single and fairly specific purpose. They are
> > used when
> > data must be transferred in real-time with very low latency. The
> best
> > example of this is audio/video but there are certainly other
> > applications for it.
> >
> > With ISO, sending packets continuously is the only way it can work.
> > Think of ISO as a stream. You need you continually read/write
> to/from
> > the stream or it will either overflow or run dry. (deepening on
> > whether
> > it is a read or write stream)
> >
> > Regards,
> > Travis
> >
> > On 10/12/2014 8:40 AM, Stephen B wrote:
> > > Hello,
> > >
> > > I'm still having trouble to understand the previous answer;
> "libusbK
> > > doesn't have transfer complete callbacks as window
> > > I/O is entirely event driven."
> > > Can anyone clarify this for me? My issue is how can I stop my
> > program
> > > from sending packets instantly, one after another.
> > >
> > > Thanks a lot in advance!
> > >
> > > Kind regards,
> > > Stephen
> > >
> > > 2014-08-31 17:50 GMT+02:00 Stephen B <[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>:
> > >
> > > Hello,
> > >
> > > Thank you, I tried to implement your procedure. This is the C#
> > > code I have: http://pastebin.com/29GZmswb
> > > I can see my device is alternating between the 3 data buffers
> (I
> > > temporarily use the data values to control LEDs). When I
> > look at a
> > > USBPcap capture I see it sends packets very rapidly: about 8000
> > > packets in 30 seconds, while my device is programmed to use one
> > > buffer every 5 seconds (very slowly for testing purposes). I
> > don't
> > > think sending packets continuously is expected behaviour, or
> > is it?
> > >
> > > Thanks in advance!
> > >
> > > Kind regards,
> > > Stephen
> > >
> > >
> > > 2014-08-29 19:41 GMT+02:00 Travis <[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>:
> > >
> > > Greetings,
> > >
> > > For ISO to work properly you must always have multiple
> > pending
> > > requests. libusbK doesn't have transfer complete
> > callbacks as
> > > window
> > > I/O is entirely event driven. The best way to handle
> > this is
> > > to create
> > > a separate thread for each of your pipes and let them be
> > > responsible for
> > > transferring data.
> > >
> > > I don't have a good C# example of how to do this but
> > consider the
> > > following pipe transfer thread proc:
> > > 1) Init overlapped pool (OvlK_Init)
> > > 2) Reset pipe (UsbK_ResetPipe)
> > > 2) submit Read #1 (OvlK_Acquire UsbK_IsoReadPipe)
> > > 3) submit Read #2
> > > 4) submit Read #3
> > > 5) MAIN LOOP (do while true)
> > > - Wait for Read #1 to complete (OvlK_Wait)
> > > - re-submit read #1 (OvlK_ReUse UsbK_IsoReadPipe)
> > > - Wait for Read #2 to complete
> > > - re-submit read #2
> > > - Wait for Read #3 to complete
> > > - re-submit read #3
> > > 6) Shut down (OvlK_Free)
> > >
> > > In the above, we are always fighting to keep 3 transfers
> > > pending all of
> > > the time. The process is the same regardless of whether
> you
> > > are reading
> > > or writing.
> > >
> > > Regards,
> > > Travis
> > >
> > > On 8/27/2014 1:20 PM, Stephen B wrote:
> > > > Hello,
> > > > Thank you very much, it works now!
> > > > Now, I asked a question on SO some time ago and
> > someone gave
> > > me a very
> > > > helpful answer, but I still don't understand the last
> > part about
> > > > callbacks:
> > > >
> > >
> >
> http://stackoverflow.com/questions/24724987/libusb-confusion-about-continous-isochronous-usb-streams
> > > > Let's say my device will also use 5 buffers, and it will
> > > output the
> > > > data with a certain frequency (not worrying about
> > > synchronization
> > > > yet). From his answer, I understand that I am able to
> > receive
> > > > callbacks once the device processes one buffer (a
> transfer
> > > of, in this
> > > > example, 64 packets). But I wonder how this is possible,
> > > because I
> > > > couldn't find anything in the usb documentation that
> > states
> > > that iso
> > > > endpoints can send some sort of confirmation that a
> buffer
> > > has been
> > > > emptied and inform the host that a new buffer must be
> > > prepared. If my
> > > > understanding is correct, WaitAndRelease returns when
> > all 64
> > > packets
> > > > have left the host, and not when the device responds with
> > > some sort of
> > > > confirmation.
> > > >
> > > > So I'm still a bit confused, I'm now thinking that a
> > secondary
> > > > endpoint (interrupt maybe?) is required to implement this
> > > callback
> > > > function. What do you suggest?
> > > >
> > > > Thanks a lot for the help so far! The lib is working and
> > > that's a big
> > > > step already :)
> > > >
> > > > Kind regards,
> > > > Stephen
> > > >
> > > >
> > > > 2014-08-26 15:57 GMT+02:00 Travis
> > <[email protected] <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>>:
> > > >
> > > > Greetings,
> > > >
> > > > 997 is the code you are looking for! It means that
> the
> > > operation
> > > > is in
> > > > progress. All of the read/write functions will
> return
> > > this when used
> > > > asynchronously. Look at the Read.Iso example again.
> > > >
> > > > 000000739.91009617[ERR](libusbK.sys)[XferIsoEx] Last
> > packet
> > > offset
> > > > references data that is out-of-range.
> > > IsoPacket[16].Offset=2048
> > > > The above line appears because the data buffer is not
> > > big enough
> > > > to hold
> > > > what is defined by the ISO packets.
> > > >
> > > > Since this is a high speed device, you will need
> > to use
> > > intervals of 8
> > > > ISO packets. Start with something simple. 64 ISO
> > > packets each
> > > > with 128
> > > > bytes.
> > > > --
> > > > // 64 packets per transfer
> > > > Iso = new IsoK(64, 0);
> > > >
> > > > // each packet holds 'MaximumPacketSize' amount of
> > data
> > > bytes
> > > > Iso.SetPackets(pipeInfo.MaximumPacketSize);
> > > >
> > > > // Create a pool of 4 overlapped contexts (we only
> > use 1
> > > here)
> > > > OvlPool = new OvlK(usb.Handle, 4,
> > KOVL_POOL_FLAG.NONE);
> > > >
> > > > // Get one of our overlapped contexts
> > > > KOVL_HANDLE ovlkHandle;
> > > > OvlPool.Acquire(out ovlkHandle);
> > > >
> > > > // Create a data buffer big enough to hold data
> > > referenced by all iso
> > > > packets
> > > > byte[] dataBuffer = new
> > byte[pipeInfo.MaximumPacketSize
> > > * 64];
> > > >
> > > > // Always issue a reset pipe prior to re/starting
> > an ISO
> > > stream.
> > > > usb.ResetPipe(pipeInfo.PipeId);
> > > >
> > > > // Submit the transfer
> > > > usb.IsoWritePipe(pipeInfo.PipeId, dataBuffer,
> > > dataBuffer.Length,
> > > > ovlkHandle, Iso.Handle/*isoCtx*/);
> > > > int errorCode = Marshal.GetLastWin32Error();
> > > > if (errorCode != ErroCodes.ErrorIoPending)
> > > > {
> > > > // TODO: something went wrong. Handle error
> > condition
> > > > }
> > > > else
> > > > {
> > > > if (!OvlPool.WaitAndRelease(ovlkHandle, 1000,
> out
> > > transferred))
> > > > {
> > > > // TODO: something went wrong. Handle error
> > > condition
> > > > }
> > > > else
> > > > {
> > > > // Success!
> > > > }
> > > > }
> > > > --
> > > >
> > > > Regards,
> > > > Travis
> > > >
> > > > On 8/26/2014 3:54 AM, Stephen B wrote:
> > > > > Hello,
> > > > >
> > > > > Right, I was using the WinUSB driver. Replaced
> > it and
> > > error 50 is
> > > > > solved but now I get error 997 (Overlapped I/O
> > > operation is in
> > > > > progress) after the write operation.
> > > > > This is the DebugView log output:
> > > > > 000000010.00000000[DriverEntry](libusbK.sys)
> > v3.0.7.0
> > > built-on:
> > > > Apr 27
> > > > > 2014 10:22:29
> > > > >
> > > 000000020.00078391(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > Found 1
> > > > > DeviceInterfaceGUIDs strings.
> > > > >
> > > 000000030.00079931(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > > > DeviceIdleEnabled=1
> > > > >
> > > 000000040.00081051(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > > > DeviceIdleIgnoreWakeEnable=0
> > > > >
> > > 000000050.00082031(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > > > UserSetDeviceIdleEnabled=0
> > > > >
> > > 000000060.00082917(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > > > DefaultIdleState=0
> > > > >
> > > 000000070.00083897(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > > > DefaultIdleTimeout=5000
> > > > >
> > > 000000080.00084877(libusbK.sys)[Registry_ReadAllDeviceKeys]
> > > > > SystemWakeEnabled=0
> > > > > 000000090.00090663(libusbK.sys)[Device_OnAdd]
> > [dev-id=#1]
> > > > > SymbolicLink=\DosDevices\libusb0-0255
> > > > > 000000100.00110821(libusbK.sys)[Device_OnAdd]
> > > [dev-id=#1] assigned
> > > > > DeviceInterfaceGUID
> > > {DE984606-810A-8A58-82DD-3568CB9B776F}.
> > > > > 000000110.00275162(libusbK.sys)[Device_Create]
> > > DeviceSpeed=High
> > > > > RemoteWakeCapable=False SelfPowered=False
> > > > > 000000120.00276701(libusbK.sys)[Device_Configure]
> > > Using single
> > > > > interface configuration..
> > > > > 000000130.00309784(libusbK.sys)[Pipe_InitContext]
> > > pipeID=00h
> > > > Creating
> > > > > pipe queue.
> > > > > 000000140.00311371(libusbK.sys)[Pipe_InitContext]
> > > pipeID=00h queue
> > > > > starting..
> > > > > 000000150.00314217(libusbK.sys)[Device_OnD0Entry]
> > > Active. D4 -> D0
> > > > > 000000166.82585812[4192]
> > > > > 000000176.82591820[4192] AllK required
> > contiguous memory =
> > > > 534200 (64bit)
> > > > > 000000186.82594538[4192] 8 HotK Handles:
> > HandleSize
> > > 2112 PoolSize
> > > > > 16912 (bytes)
> > > > > 000000196.82597113[4192] 64 LstK Handles:
> > HandleSize
> > > 64 PoolSize
> > > > > 4112 (bytes)
> > > > > 000000206.82599640[4192] 1024 LstInfoK Handles:
> > > HandleSize 64
> > > > > PoolSize 65552 (bytes)
> > > > > 000000216.82602358[4192] 64 UsbK Handles:
> > HandleSize
> > > 96 PoolSize
> > > > > 6160 (bytes)
> > > > > 000000226.82604837[4192] 32 DevK Handles:
> > HandleSize
> > > 112 PoolSize
> > > > > 3600 (bytes)
> > > > > 000000236.82607317[4192] 4096 OvlK Handles:
> > > HandleSize 104
> > > > PoolSize
> > > > > 426000 (bytes)
> > > > > 000000246.82609797[4192] 64 OvlPoolK Handles:
> > > HandleSize 96
> > > > PoolSize
> > > > > 6160 (bytes)
> > > > > 000000256.82612276[4192] 32 StmK Handles:
> > HandleSize
> > > 176 PoolSize
> > > > > 5648 (bytes)
> > > > > 000000266.82614470[4192]
> > > > > 000000276.82617807[4192] Dynamically allocated
> > as needed:
> > > > > 000000286.82620192[4192] KLST_DEVINFO = 2596
> > bytes each
> > > > > 000000296.82862473[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB\4&22692171&0..
> > > > > 000000306.82866192[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB\4&2C0CBE2A&0..
> > > > > 000000316.82870102[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB\4&2EA0F109&0..
> > > > > 000000326.82873869[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB\4&8756F75&0..
> > > > > 000000336.82877636[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB\4&BB39B4E&0..
> > > > > 000000346.82881403[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB20\4&36D5FDB7&0..
> > > > > 000000356.82885361[4192]
> > > (libusbK.dll)[l_EnumKey_Guids] Skipping
> > > > > USB\ROOT_HUB20\4&7B02F80&0..
> > > > > 000000366.84401226[4192] LstK Init: handle
> > > 0x000000001B72EE58
> > > > >
> 000000376.88146448(libusbK.sys)[Device_OnFileCreate]
> > > begins
> > > > >
> 000000386.88147306(libusbK.sys)[Device_OnFileCreate]
> > > Process ID=4192
> > > > >
> > 000000396.88148260(libusbK.sys)[Device_OnFileCreate] ends
> > > > > 000000406.88162613(libusbK.sys)[XferCtrl]
> > > bmDir=DeviceToHost(1)
> > > > > bmType=Standard(0) bmRecipient=Device(0)
> > > bmReserved=000 bRequest=6
> > > > > wIndex=0 wValue=512 wLength=0
> > > > > 000000416.88164711(libusbK.sys)[XferCtrl]
> > > bmDir=DeviceToHost(1)
> > > > > bmType=Standard(0) bmRecipient=Device(0)
> > > bmReserved=000 bRequest=6
> > > > > wIndex=0 wValue=512 wLength=0
> > > > > 000000426.88214540[4192]
> > (libusbK.dll)[k_Init_Version]
> > > libusbK.sys
> > > > > v3.0.7.0
> > > > > 000000436.88220263[4192] UsbK Init: handle
> > > 0x000000001B73FE78
> > > > >
> > 000000446.88879156(libusbK.sys)[Interface_SetAltSetting]
> > > > selected alt
> > > > > setting index 1 on interface number 0
> > > > >
> > 000000456.88880396(libusbK.sys)[Interface_InitContext]
> > > > configured Read
> > > > > pipe: PipeID=81h MaximumPacketSize=64
> > > MaximumTransferSize=262144
> > > > > PipeType=Interrupt
> > > > >
> > 000000466.88881016(libusbK.sys)[Interface_InitContext]
> > > configured
> > > > > Write pipe: PipeID=02h MaximumPacketSize=64
> > > > MaximumTransferSize=262144
> > > > > PipeType=Interrupt
> > > > >
> > 000000476.88881588(libusbK.sys)[Interface_InitContext]
> > > > configured Read
> > > > > pipe: PipeID=83h MaximumPacketSize=512
> > > MaximumTransferSize=2097152
> > > > > PipeType=Bulk
> > > > >
> > 000000486.88882160(libusbK.sys)[Interface_InitContext]
> > > configured
> > > > > Write pipe: PipeID=04h MaximumPacketSize=512
> > > > > MaximumTransferSize=2097152 PipeType=Bulk
> > > > >
> > 000000496.88882971(libusbK.sys)[Interface_InitContext]
> > > > configured Read
> > > > > pipe: PipeID=85h MaximumPacketSize=128
> > > MaximumTransferSize=131072
> > > > > PipeType=Isochronous
> > > > >
> > 000000506.88883543(libusbK.sys)[Interface_InitContext]
> > > configured
> > > > > Write pipe: PipeID=06h MaximumPacketSize=128
> > > > > MaximumTransferSize=131072 PipeType=Isochronous
> > > > > 000000516.88883972(libusbK.sys)[Pipe_InitContext]
> > > pipeID=81h
> > > > Creating
> > > > > pipe queue.
> > > > >
> > 000000526.88884449(libusbK.sys)[Pipe_InitQueueConfig]
> > > Configuring
> > > > > sequential queue..
> > > > > 000000536.88885784(libusbK.sys)[Pipe_InitContext]
> > > pipeID=81h queue
> > > > > starting..
> > > > > 000000546.88886356(libusbK.sys)[Pipe_InitContext]
> > > pipeID=02h
> > > > Creating
> > > > > pipe queue.
> > > > >
> > 000000556.88886690(libusbK.sys)[Pipe_InitQueueConfig]
> > > Configuring
> > > > > sequential queue..
> > > > > 000000566.88887310(libusbK.sys)[Pipe_InitContext]
> > > pipeID=02h queue
> > > > > starting..
> > > > > 000000576.88887644(libusbK.sys)[Pipe_InitContext]
> > > pipeID=83h
> > > > Creating
> > > > > pipe queue.
> > > > >
> > 000000586.88888025(libusbK.sys)[Pipe_InitQueueConfig]
> > > Configuring
> > > > > sequential queue..
> > > > > 000000596.88888645(libusbK.sys)[Pipe_InitContext]
> > > pipeID=83h queue
> > > > > starting..
> > > > > 000000606.88889027(libusbK.sys)[Pipe_InitContext]
> > > pipeID=04h
> > > > Creating
> > > > > pipe queue.
> > > > >
> > 000000616.88889408(libusbK.sys)[Pipe_InitQueueConfig]
> > > Configuring
> > > > > sequential queue..
> > > > > 000000626.88889933(libusbK.sys)[Pipe_InitContext]
> > > pipeID=04h queue
> > > > > starting..
> > > > > 000000636.88890314(libusbK.sys)[Pipe_InitContext]
> > > pipeID=85h
> > > > Creating
> > > > > pipe queue.
> > > > >
> > 000000646.88890648(libusbK.sys)[Pipe_InitQueueConfig]
> > > Configuring
> > > > > parallel queue..
> > > > > 000000656.88891411(libusbK.sys)[Pipe_InitContext]
> > > pipeID=85h queue
> > > > > starting..
> > > > > 000000666.88891745(libusbK.sys)[Pipe_InitContext]
> > > pipeID=06h
> > > > Creating
> > > > > pipe queue.
> > > > >
> > 000000676.88892078(libusbK.sys)[Pipe_InitQueueConfig]
> > > Configuring
> > > > > parallel queue..
> > > > > 000000686.88892603(libusbK.sys)[Pipe_InitContext]
> > > pipeID=06h queue
> > > > > starting..
> > > > > 000000696.89122868[4192] LstK Dispose: Freed
> > > > Handle:000000001B72EE58h
> > > > > Explicit:True
> > > > > 000000709.90101719[4192] IsoK Init: handle
> > > 0x000000001B6BFD00
> > > > > 000000719.90591049[4192] OvlK Init: handle
> > > 0x000000001B7AA4A8
> > > > > 000000729.90827751(libusbK.sys)[Pipe_Reset]
> > pipeID=06h
> > > > > 000000739.91009617[ERR](libusbK.sys)[XferIsoEx]
> Last
> > > packet offset
> > > > > references data that is out-of-range.
> > > IsoPacket[16].Offset=2048
> > > > > 000000749.91096878[4192]
> > [ERR](libusbK.dll)[OvlK_Wait]
> > > Unknown
> > > > > OverlappedK failure. errorCode=000006F8h
> > > > > 000000759.91620255[4192] UsbK Dispose: Freed
> > > > Handle:000000001B73FE78h
> > > > > Explicit:True
> > > > > 000000769.92062855[4192] IsoK Dispose: Freed
> > > > Handle:000000001B6BFD00h
> > > > > Explicit:True
> > > > >
> > 000000779.92470455(libusbK.sys)[Interface_ReleaseAll]
> > > releasing all
> > > > > interfaces bound to file object 0x51c5350
> > > > > 000000789.92471409(libusbK.sys)[Device_OnFileClose]
> > > > > OpenedFileHandleCount=0
> > > > > 000000799.92485809[4192] OvlK Dispose: Freed
> > > > Handle:000000001B7AA4A8h
> > > > > Explicit:True
> > > > >
> > > > > I see something is out of range, so I tried
> reducing
> > > the number of
> > > > > packets per transfer, but no luck. I think I need
> to
> > > solve the 997
> > > > > error first. I wonder what's causing it?
> > > > >
> > > > > Kind regards,
> > > > > Stephen
> > > > >
> > > > >
> > > > > 2014-08-25 23:34 GMT+02:00 Travis
> > > <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>
> > > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>> <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>>>:
> > > > >
> > > > > Greetings,
> > > > >
> > > > > Ensure that you have installed the
> "libusbK.sys"
> > > driver with
> > > > your
> > > > > device
> > > > > and not the WinUSB driver. However, if this was
> > > the problem
> > > > then I
> > > > > would not expect the read iso example to
> > work either.
> > > > >
> > > > > If that doesn't help, you can also install the
> > > debug version
> > > > of the
> > > > > library and driver and use DebugView to see the
> > > messages. For
> > > > > instruction on this there are several posts
> > in the
> > > archives.
> > > > >
> > > > > Regards,
> > > > > Travis
> > > > >
> > > > > On 8/25/2014 2:55 PM, Stephen B wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I am trying to write isochronous data to
> > my USB
> > > device. I
> > > > tried
> > > > > > the xfer-iso c example but had no luck to
> > > compile it, and
> > > > > preferably I
> > > > > > want to use C# anyway. So I looked at the C#
> > > examples and
> > > > found
> > > > > > Read.Isochronous. This compiles and works,
> but
> > > unfortunately
> > > > > there is
> > > > > > no Write example.
> > > > > >
> > > > > > I tried to create it myself using the c
> > example and
> > > > > > the Read.Isochronous example, but with no
> luck
> > > yet. When
> > > > > writing, the
> > > > > > following line always returns error 50 (the
> > > request is not
> > > > > supported):
> > > > > > usb.IsoWritePipe(pipeInfo.PipeId, dataBuffer,
> > > > dataBuffer.Length,
> > > > > > ovlkHandle, Iso.Handle);
> > > > > >
> > > > > > I also can't find any iso out packets with
> > USBPcap.
> > > > > >
> > > > > > Does anyone have any idea what's causing
> > this? I
> > > have attached
> > > > > my code
> > > > > > along with a descriptor report of my device.
> > > There are 5
> > > > unnecessary
> > > > > > endpoints from my base firmware code, but I
> > > decided to
> > > > keep them in
> > > > > > for now to prevent causing more bugs, as my
> > > device has
> > > > worked and
> > > > > > transferred iso data with libusb in the past.
> > > > > >
> > > > > > Thanks in advance for any help!
> > > > > >
> > > > > > Kind regards,
> > > > > > Stephen
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > > > Slashdot TV.
> > > > > > Video for Nerds. Stuff that matters.
> > > > > > http://tv.slashdot.org/
> > > > > >
> > > > > >
> > > > > >
> > _______________________________________________
> > > > > > Libusb-win32-devel mailing list
> > > > > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>
> > > > >
> > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>>
> > > > > >
> > > >
> > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > > Slashdot TV.
> > > > > Video for Nerds. Stuff that matters.
> > > > > http://tv.slashdot.org/
> > > > > _______________________________________________
> > > > > Libusb-win32-devel mailing list
> > > > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>
> > > > >
> > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>>
> > > > >
> > > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > > Slashdot TV.
> > > > > Video for Nerds. Stuff that matters.
> > > > > http://tv.slashdot.org/
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Libusb-win32-devel mailing list
> > > > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>
> > > > >
> > > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> > > >
> > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > Slashdot TV.
> > > > Video for Nerds. Stuff that matters.
> > > > http://tv.slashdot.org/
> > > > _______________________________________________
> > > > Libusb-win32-devel mailing list
> > > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>>
> > > >
> > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > Slashdot TV.
> > > > Video for Nerds. Stuff that matters.
> > > > http://tv.slashdot.org/
> > > >
> > > >
> > > > _______________________________________________
> > > > Libusb-win32-devel mailing list
> > > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > >
> > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > Slashdot TV.
> > > Video for Nerds. Stuff that matters.
> > > http://tv.slashdot.org/
> > > _______________________________________________
> > > Libusb-win32-devel mailing list
> > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
> > Reports
> > > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White
> paper
> > > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog
> Analyzer
> > > http://p.sf.net/sfu/Zoho
> > >
> > >
> > > _______________________________________________
> > > Libusb-win32-devel mailing list
> > > [email protected]
> > <mailto:[email protected]>
> > > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Comprehensive Server Monitoring with Site24x7.
> > Monitor 10 servers for $9/Month.
> > Get alerted through email, SMS, voice calls or mobile push
> > notifications.
> > Take corrective actions from your mobile device.
> > http://p.sf.net/sfu/Zoho
> > _______________________________________________
> > Libusb-win32-devel mailing list
> > [email protected]
> > <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Comprehensive Server Monitoring with Site24x7.
> > Monitor 10 servers for $9/Month.
> > Get alerted through email, SMS, voice calls or mobile push notifications.
> > Take corrective actions from your mobile device.
> > http://p.sf.net/sfu/Zoho
> >
> >
> > _______________________________________________
> > Libusb-win32-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libusb-win32-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
------------------------------------------------------------------------------
_______________________________________________
Libusb-win32-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel