Windows 7 hangs when trying to use USB camera device

Hi,

Yesterday I installed the VirtualHere server on my Raspberry Pi and the VirtualHere client on my Windows 7 PC.
I started the server application on Raspberry Pi and then the client application on the PC.
The client correctly detects and shows the USB camera device (by its id). When i select 'use this device', an unknown device appears in the Windows device manager. I then provide Windows with the correct driver for the camera (the camera is a Celestron Neximage planetary webcam for which a Philips SPC 900NC PC Camera driver is used).
As the final step I start the AM Capture camera control application and select the camera device.
Now Windows 7 hangs completely.

(BTW: The AM capture control program works fine when the camera is directly connected to the PC.)

Any idea why Windows hangs here?

B R
Joakim

#2

At the moment VirtualHere running on Raspberry Pi will not work with webcams, its a bug in the kernel which im hoping they will fix.

I see. But could this really result in a crash on the PC side?
I could understand if Raspberry PI crashed due to the bug but having a crash of the PC due to a bug on the Raspberry PI side seems really strange...

Any way, do you have a reference to a discussion about the bug you mention?

I tested running the VH server on an Ubuntu PC and the VH client on a Windows 7 PC and now it works!

The performance seems to be good (can't tell for sure how good it is as my camera doesn't have a lense so I can only see changes in intensity).
I would like to have real-time performance though in order to be able to create short movies (640 x 480@5 fps).
Is that possible with average laptop performance on both sides (client & server)?
Will it (when the bug you mentioned is fixed) be possible also with Raspberry Pi as server?

Yes i have spent considerable time trying to figure this bug out and i found what happens.

When virtualhere calls into the kernel it passes an "Isochronous" request for data from the device. But the call to the kernel never returns even though its meant to straight away. This only seems to happen in the raspberry pi and specifically inside the usb hub driver. As you have found out it works fine on other platforms.

There is a thread about this at http://www.raspberrypi.org/phpBB3/viewtopic.php?t=23544

For your other items:

Webcams use Isochronous transfer which means "give me as much data from the device as possible as fast as possible" and therefore is very CPU intensive. The faster your CPU the better frame rate you will acheive. Eventually when they fix the raspbian kernel it will work, however i my guess would be a framerate of 320x240x5frames using the raspberry pi. The actual raspberry pi hardware is NOT open source hence i dont know how to fix the kernel. If it was open source i would take a look at the raspbian kernel myself.

You could always buy another arm based board such as http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G1… which will provide considerably more processing power and I could compile VirtualHere for that.

#7

Hi,
I have been testing the use of webcams on the raspberry pi, and I came across a function in some webcams which captures still images (Still Pin). Do you think the raspberry pi kernel uses the same Isochronous transfer using the still pin?

As far as I know, webcams uses a function call "Capture PIN" to capture videos.

In reply to by Aldis

#8

Hi Aldis, Im not sure about that. Try a usb tracing program such as usblyzer.com or similar. That will show the exact methodology it uses to capture still pictures. if its not isochonous then it should work.

#9

Hey, I recently got my hands on a webcam(V-gear talkcam) which uses Bulk transfer mode instead of Isochronous. I can't get images to come back to me properly. All I got was glitches.
Tried it at the lowest resolution of 160x120 @5fps.
http://i42.tinypic.com/zoimo.jpg

Got VirtualHere to work with fingerprint readers. The readers works like scanners, they run on Bulk mode.
So I was wonder if Raspberry Pi's USB bandwidth(shared with LAN as well right?) is inadequate for transmitting video images.
Any take on this?

#10

Yes fingerprint readers, scanners, printers etc use Control transfers to setup the connection then a bunch of bulk transfers to do the data transfer. Im pretty sure that webcam uses isochronous because all webcams do. If you tried tracing the packets using usblyzer they you would see a lot of control packets setting up the frame rate, resolution etc then a few interrupt transfers and bulk transfers for control synchronization and then a lot of isochronous packets. You would then probably see a continuous stream of isochronous transfers but likely with invalid data in them from the pi.

I have actually used the USB analyzer, it does show control for setting up and a continuous streams bulk packets instead of isochronous. Infact, not a single isochronous packet was sent during the test process.
The webcam I currently have only has bulk endpoints, not isochronous.
So I was wondering why only the first fuzzy frame is recieved on my client PC. Does Virtual Here support continuous bulk transfers? Or is there a "delay" between bulk transfer packets? Which might cause my webcam stream to freeze up on receiving the first frame.

#12

Aldis, could you see if it works with Ubuntu Desktop as the server rather than the raspberry. Im thinking the raspberry might just be too slow to keepup with the framerate if indeed it is using bulk transfers for images....

Hey man,
I tried with Ubuntu through VM. Still got a single glitch image.
And since previous user mentioned that Isochronous webcams are working on Ubuntu(not raspberry pi), I proceeded to try it too.
I got black screen from 3 different webcams. Just can't get any single webcam to work regardless of server platform(RaspberryPi,Ubuntu12.04).
Kind of at my wits end now. lol

#14

OK for time being i dont think your particular webcam is going to work. I am always updating the client so perhaps in the future it might...