Re: LibUsbK Isochronous Write C# example
Travis <[email protected]> Mon, 27 Oct 2014 11:17:26 -0600
| Newsgroups | gmane.comp.lib.libusb.devel.windows |
|---|---|
| Message-ID | <[email protected]> |
Greetings,
I believe that no matter what, the lower USB drivers in windows are
going to poll your device at the poll rate specified in the endpoint
descriptor. By setting the start frame, you are merely telling it to
ignore all ISO packets that are received before said start frame.
I often refer people to this msdn page:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225%28v=vs.85%29.aspx
There is a heap of good information specific to ISO pipes/transfers.
In a nut shell, the only way to change the poll rate if an ISO pipe is
to set the bInterval value in the endpoints descriptor. A major caveat
of this is Windows only works with certain bInterval values so it's hard
to get the exact polling rate you want. The "allowed" bInterval values
are different for full speed/high speed devices. See the link above.
Regards,
Travis
On 10/22/2014 2:19 PM, Stephen B wrote:
> 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]
> <mailto:[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>
> >
> <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]>
> > <mailto:[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]>>
> > > <mailto:[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]>>
> > > <mailto:[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]>>>
> > > > <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,
> > > >
> > > > 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]>>>>
> > > > > <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]
> <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]>>>>
> > > > >
> > <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]
> <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]>>>>
> > > > >
> > <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]
> <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]>>>
> > > >
> <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
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > 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]>
> > <mailto:[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]>
> > <mailto:[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
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libusb-win32-devel mailing list
> [email protected]
> <mailto:[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
------------------------------------------------------------------------------