Hi Nathan,
Increasing the frame increment reduces the number of errors somewhat,
but the same errors still occur enough to fill the log file very very
fast... I tried various values for the frame increment. The
reduction in data loss between `frame += 4` and `frame += 1000` is
about 5% (using 8
Thanks, Tim. I'll forward the information to the hardware/firmware developers.
On Mon, Jun 25, 2012 at 7:43 PM, Tim Roberts wrote:
> Ellis Whitehead wrote:
>> I had hoped that I could make some progress by investigating this
>> further myself, but wasn't able to figure much out...
>> ...
>>
Thanks for taking the time to look at the source code, Xiaofan.
> Anyway just a wild guess here. What if you increase the
> ISO_PACKETS_PER_TRANSFER from 8 to 16 or even higher (say 64),
> does that help?
The increase results in the same behavior, just with more packets per
transfer being reporte
On Tue, Jun 26, 2012 at 4:52 AM, Nathan Hjelm wrote:
> If the transaction should be working the user could try to change how far in
> the future the isoc transaction is scheduled for. He can do this by changing
> line 1370 (in 1.0.9) from:
>
> frame += 4;
> to
> frame += 6;
>
> or something simila
If the transaction should be working the user could try to change how far in the future the isoc transaction is scheduled for. He can do this by changing line 1370 (in 1.0.9) from:frame += 4;toframe += 6; or something similar.-NathanOn Jun 24, 2012, at 08:28 PM, Xiaofan Chen wrote:On Sun, Jun 24,
Ellis Whitehead wrote:
> I had hoped that I could make some progress by investigating this
> further myself, but wasn't able to figure much out...
> ...
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber0
> bAlter
On Sun, Jun 24, 2012 at 8:27 PM, Ellis Whitehead
wrote:
> I had hoped that I could make some progress by investigating this
> further myself, but wasn't able to figure much out... It seems to me
> in the log file that I posted, the log entry of most interest is this
> one:
> libusbx: debug [darw
I had hoped that I could make some progress by investigating this
further myself, but wasn't able to figure much out... It seems to me
in the log file that I posted, the log entry of most interest is this
one:
libusbx: debug [darwin_handle_callback] handling isoc completion
with kernel status -5
On Sun, Jun 17, 2012 at 10:33 PM, Ellis Whitehead
wrote:
>>> You can produce detailed debug log if you set the environmental
>>> variable LIBUSB_DEBUG to 4. That debug log may help to identify
>>> the potential problem.
>
> Ok, I've uploaded it here:
> http://gcead.sourceforge.net/libusbx-debug-20
>> When libusbx-1.0.13 integrates libusb0.sys support, you might be
>> able to consolidate to use libusbx if isochronous support is added
>> to libusbx.
That'd be great. I'll try it once it's available.
>> Hmm, there is no such version as libusbx-1.0.14, do you mean
>> libusbx-1.0.12?
Woops; ye
To Ellis: please subscribe to the mailing list. Thanks.
On Sun, Jun 17, 2012 at 9:08 PM, Xiaofan Chen wrote:
> On Sun, Jun 17, 2012 at 7:08 PM, Ellis Whitehead
> wrote:
>> I have a project http://gcead.sourceforge.net/ that records data from
>> an isochronous acquisition device. The USB communi
On Sun, Jun 17, 2012 at 7:08 PM, Ellis Whitehead
wrote:
> I have a project http://gcead.sourceforge.net/ that records data from
> an isochronous acquisition device. The USB communication utilizes
> libusbx on linux and libusb-win32 on windows, and both work fine
> (thanks!).
Great. Thanks for th
I have a project http://gcead.sourceforge.net/ that records data from
an isochronous acquisition device. The USB communication utilizes
libusbx on linux and libusb-win32 on windows, and both work fine
(thanks!).
On mac, however, data is frequently dropped, and we see the following
error message r
13 matches
Mail list logo
