Glview broken with recent changes about libfreenect

[qdot]

So, the LED /should/ be red, that was added to the new program. However, otherwise it works fine for me (I tested it before integrating into master). I can't repro your bug here.

When had you updated before this? Have you repatched libusb and reinstalled as of commit 562a7b2? This sounds like a symptom of that. There's also a memory leak that I'm about to patch in libusb, so watch master and be ready to repatch. :)

[0x736E]

I deleted all repos and pulled down the latest version, also merging new changes to my fork, still getting this error.

Since I use my osx-setup.sh script, the latest version of libusb is grabbed, patched and installed by default.

[qdot]

We're still not getting any other reports of this on OS X, and it's still working fine for me. Are you sure your old libusb is getting removed?

[qdot]

Ok, we're starting to get other reports of this now in the IRC channel. It's being worked on as we speak.

What video card does your mac have?

[0x736E]

NVIDIA GeForce GT 120. Heres some other details in case it helps:

Model Name: Mac Pro
Model Identifier: MacPro4,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.26 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB
Memory: 8 GB
NVIDIA GeForce GT 120:

Mac OSX 10.6.5

[marcan]

Is this still an issue? Recent reports of -99 were related to USB bandwidth issues, and things seem to be working fine on OS X as far as I know.

[mirek]

Seems still an issue on MB Pro, Snow Leopard.
Tested with:

* todays clone of libfreenect and libusb
* and todays libfreenect and libusb (7da756e) with osx patch

code:

freenect_init(&ctx, NULL);
freenect_open_device(ctx, &dev, 0);
freenect_set_log_level(ctx, FREENECT_LOG_FLOOD);
freenect_set_depth_format(dev, FREENECT_FORMAT_11_BIT);
freenect_start_depth(dev);

log:

Creating EP 82 transfer # 0
Creating EP 82 transfer # 1
Failed to submit isochronous transfer 1: -99
Creating EP 82 transfer # 2
Failed to submit isochronous transfer 2: -99
Creating EP 82 transfer # 3
Failed to submit isochronous transfer 3: -99
Write Reg 0x0006 <= 0x00
Control cmd=0003 tag=0000 len=0004: 12
Isochronous transfer error: 1
Control reply: 12
Write Reg 0x0012 <= 0x03
Control cmd=0003 tag=0001 len=0004: 12
Control reply: 12
Write Reg 0x0013 <= 0x01
Control cmd=0003 tag=0002 len=0004: 12
Control reply: 12
Write Reg 0x0014 <= 0x1e
Control cmd=0003 tag=0003 len=0004: 12
Control reply: 12
Write Reg 0x0006 <= 0x02
Control cmd=0003 tag=0004 len=0004: 12
Control reply: 12

Leds and motor are working fine; rgb and depth fail.

[qdot]

Are you using a USB hub? If so, that may be the culprit, as the camera may need to be plugged in directly to the machine. However, there's also reports that it may need to be on the first bus of the machine too. Try connecting to different ports and see what happens.

[mirek]

Connected directly without hub.

Tried connecting directly to 1st, 2nd and 3rd usb port (macbook pro has 3 usb ports).
Nothing else was connected.

Same results, leds are fine, motor works perfectly, rgb and depth generates errors.

[wandroid]

I'm seeing this exact same problem on a 13" MacBook Pro 2.66 Ghz Core Duo system running Snow Leopard 3.6.5. I've hacked out the starting of the RGB and IR camera threads, and can control the motor and LED just fine. I caught a trace of the enumeration and launch of glview with a Beagle 480 analyzer if anyone's interested. I've never tried to look into the USB protocol at this level, so I'm not getting very far with debug, other than It seems to fail to accept the first isochronous transfer requests for the two camera data endpoints.

[wandroid]

In the analyzer trace, Xbox NUI Motor, Xbox NUI Audio, and Xbox NUI Camera show up as devices 4, 5, and 6 respectively. There is also a device 2 which is labeled as an "Unknown Device". This device has an IN and OUT EP defined as 1 and 2. The very first transaction to this device is a 'SETUP" and is marked in red in the trace with an error indicating "Invalid PID sequence". All transactions to device two are "SETPUP" transactions and fail the same way. My skills are not yet up to determining if this is related to the failure of the isochronous transfers reported by the code.

[wandroid]

Posted the zip'd Beagle trace file at:

http://web.me.com/nazrobia/Beagle_Trace_file

Viewer is Total Phase Data Center which is a free download from:

http://www.totalphase.com/products/beagle_usb480/

[mirek]

According to google http://libusb.6.n5.nabble.com/BUG-Darwin-isochronous-transfers-td396026.html :

"(...)[this] error usually results from the packet being
scheduled too far in the past (or future). In the Darwin
backend I set isoch packets to be scheduled two frames
after the current frame. You might try increasing that to
3 frame and see if it works. (...)"

[wandroid]

So you're talking about the following code, that was part of the patch to libusb? from
darwin_usb.c:

/* schedule for a frame a little in the future */
frame += 2;

/* submit the request /
if (is_read)
kresult = ((cInterface->interface))->ReadIsochPipeAsync(cInterface->interface, pipeRef, transfer->buffer, frame,
transfer->num_iso_packets, tpriv->isoc_framelist, darwin_async_io_callback,
itransfer);
else

I've tried varying that value from 1 to 5, and I still get the same results. I may be misinterpreting your response. Thanks for the reference, I'll poke around that thread.

Pretty sure I'm picking up tge changes ok, since I can change the debug output in libusb and I get the expected changes after rebuilding glview.

Tried both ports on the 13" MBP
The error is consistently:

Kinect camera test
Number of devices found: 1
GL thread
Failed to submit isochronous transfer 1: -99
Failed to submit isochronous transfer 2: -99
Failed to submit isochronous transfer 3: -99
Write Reg 0x0006 <= 0x00
Write Reg 0x0012 <= 0x03
Write Reg 0x0013 <= 0x01
Write Reg 0x0014 <= 0x1e
Write Reg 0x0006 <= 0x02
Isochronous transfer error: 1
Failed to submit isochronous transfer 1: -99
Failed to submit isochronous transfer 2: -99
Failed to submit isochronous transfer 3: -99
Write Reg 0x0005 <= 0x00
Write Reg 0x000c <= 0x00
Write Reg 0x000d <= 0x01
Write Reg 0x000e <= 0x1e
Write Reg 0x0005 <= 0x01
Isochronous transfer error: 1
Write Reg 0x0047 <= 0x00
'w'-tilt up, 's'-level, 'x'-tilt down, '0'-'6'-select LED mode
raw acceleration: -1 780 3 mks acceleration: -0.011974 9.339667 0.035922

Another odd thing is that it takes nearly a minute before this accelerometer output appears. I'm wondering if I'm getting a bunch of timeouts that are causing this to be slow. Should be able to tell if I run the analyzer a little longer.

[qdot]

It takes a lot more than changing the frames.

https://github.com/OpenKinect/libfreenect/blob/master/platform/osx/libusb-osx-kinect.diff

[qdot]

This really isn't something that should require the analyzer either. This isn't a line problem, it's probably something in how we're dealing with OS X.

[wandroid]

Sorry, didn't mean to imply that the frame count is the only change related to the patch. I've applied all of the changes in the diff file for version OpenKinect-libfreenect-0aa8323,
although I did apply them to a more recent libusb-1.0.8 than the snapshot mentioned in the README.asciidoc file. I didn't know how to build the one in the snapshot since it doesn't seem to have the cmake infrastructure that I'm familiar with. My reasoning was that using the more recent libusb was not likely to be an issue as long as I applied all of the patches. As for the analyzer, it's helping me learn the protocol more than anything else at this point.

[wandroid]

I would be curious to know what OSX patforms this implementation DOES work on. From stuff I've read in the ADC Developer's documentation, there can be really long delays between the issuing of isochronous requests and the callback. It appears that the libusb code is not reentrant, and I assume that the issue has to do with isochronous transfers stacking up (or not able to stack up). All I can figure is that this problem may be worse on some platforms than others, or the patched libusb code works around this problem, and I have not successfully applied the patches. Probably going to punt and try my own IOKit solution for the device interface.

[qdot]

So, I test every commit against OS X before pulling into unstable, and it works on my core duo 2.8ghz mbp with 10.6.5, nvidia video card. But that's all I've seen it run on in terms of OS X, haven't tried anything else.

If you get a pure IOKit solution going, please let us know. libusb and OS X have never been friends, and I'm all for getting the lowest levels working in platform specific APIs since we've got it pretty minimal and abstracted away now.

[RobotJINI]

I got this error when I plugged in my kinetic through a usb3.0 port. Switching to a 2.0 solved the problem.