New libusb version not working on AMD

[kohrt]

I just tried out the updated libusb from #149. On the Intel board it is working fine, but on an AMD board it justs says working buffer full, resetting it! and is not receiving depth frames anymore.

[xlz]

#149 is not really changing anything. working buffer full, resetting it means the magic footer is not found through 512*424*11/8*2 bytes, but it should within 512*424*11/8 bytes. So I guess you are getting packet loss. Maybe you can add some logging code in DepthPacketStreamParser::onDataReceived and see how the transfers look.

[kohrt]

I know, I don't think that it is a problem of libfreenect2, but maybe some regressions in libusb. With the previous version of libusb receiving depth images works, but as soon as I check out the more recent master version where MAX_ISO_BUFFER_LENGHT is changed, no frames are received.

[xlz]

What about a bisection of libusb?

[kohrt]

what do you mean with bisection of libusb?

[xlz]

git bisect
Start with a good commit, Go to a bad commit, and git bisect will tell you which commit to test, then you identify a particular commit...

[floe]

So since we know that v1.0.19 was OK, and 51b10191033ca3a3819dcf46e1da2465b99497c2 is not, you would do something like the following in the depends/libusb folder:

git bisect start
git bisect bad
git bisect good v1.0.19

git will checkout a version in between the two commits, then you build & test that version and run git bisect {good|bad} afterwards, depending on whether it worked or not. After a few iterations, git will (hopefully) tell you the exact commit which causes the issue.

[kohrt]

Thanks for the explanation. I didn't know this functionality before. I will try it out.

[kohrt]

I did the git bisect and it turns out that exactly this commit introduced the problem.

The MAX_ISO_BUFFER_LENGTH was changed to 49152 * 128, but as soon as I change it to just 49152 it works again. Any value higher than 67583 will not work.

[christiankerl]

OK so I guess we have to revert this change to libfreenect2, submit a bug report to libusb and re-apply it after they've fixed it

[floe]

Does libusb HEAD work by any chance, i.e. does a later commit maybe fix this anyway?

[kohrt]

I also tried HEAD, but that does not help. I also tried out a 3.18 kernel instead of the 3.16, but this does not solve the problem either.

[larshg]

@wiedemeyer what is the actual transfers you get in each "packet"? 49152 * 128 seems like a awful lot of bytes in one transfer? - On windows its 33792 bytes.

I guess it shouldn't matter how many bytes is transfers per "packet" as along as the whole packet is received?

Maybe you could try my go (#75) at the depth packet parsing or @xlz go (I have a branch with his changes also)?

[christiankerl]

49152 * 128 is just an upper bound used by libusb for some internal checks