What would certainly create "crossover" in between 2 USB2 cams when making use of activity?
I am making use of the Motion plan for linux to work as a protection system with 2 Microsoft LifeCam HD - 5000 cams. As a whole it is functioning quite possibly yet I'm experiencing an unusual concern. Every so often the feed from one web cam will certainly show "crosstalk" or "crossover" from the various other web cam, in sweeping bars, ideal defined in this photo (highlighted in red):
As you can see, the photo is a combined mess of the within and also the outdoors camera feeds. I think this article from Motion's wiki is defining the very same concern, nonetheless there is no remedy there besides:
If you require greater than 1 USB camera add added USB PCI cards to your computer system
However that is speaking about USB 1.1, and also these are USB 2.0 electronic cameras. Additionally, I do think this system has 2 UCB cards which the electronic cameras are attached to 2 various USB busses:
[email protected]:~# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M |__ Port 2: Dev 3, If 0, Class=stor., Driver=usbfs, 480M |__ Port 3: Dev 4, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M |__ Port 3: Dev 4, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M |__ Port 3: Dev 4, If 2, Class=audio, Driver=snd-usb-audio, 480M |__ Port 3: Dev 4, If 3, Class=audio, Driver=snd-usb-audio, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M |__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 12M |__ Port 3: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 4: Dev 5, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M |__ Port 4: Dev 5, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M |__ Port 4: Dev 5, If 2, Class=audio, Driver=snd-usb-audio, 480M |__ Port 4: Dev 5, If 3, Class=audio, Driver=snd-usb-audio, 480M [email protected]:~# lspci 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 12) 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) 00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06) 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06) 00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 (rev 06) 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06) 00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller (rev 06) 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) 02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM57788 Gigabit Ethernet PCIe (rev 01)
So my inquiries are:
- Does any person recognize what could create crossover similar to this?
- Any kind of various other troubleshooting pointers?
- I am presuming I will require to ask the programmers of Motion for assistance, so prior to I do, can any person validate that I do have the electronic cameras attached to 2 various PCI cards as they recommended?
To the first factor : USB1.1 was a lot slower than USB2.0, in the majority of cirumstances. Keep in mind that tools can still connect at the lower 1.1 rate of 12Mbps as opposed to the faster 480Mbps, yet generally when this happens it is either due to the fact that the port is autonegotiating reduced or it is due to the fact that among both tools is actually 1.1. Attempt disconnecting and also reconnecting if you experience this and also make certain both are 2.0 and also your OS has assistance for 2.0. (basic suggestions, ya?) ~ ~ Anyways, that was why they advised a new card. To make sure that you can make use of the complete USB1.1 rate per specific camera given that the PCI bus is means much faster than USB1.1. Yet with 2.0 that is not essential. [dead steed flogged, taking place to next subject ]
Now onto your tool especially. You've a Core i5 by the majority of plausible metrics, particularly : Intel 5/ 3400 collection PCH and also 82801PCI bridge. (side note : validated that he has a Dell Core i5) This certain PCH is additionally code - called Ibex Peak. You no more have an independent southbridge (as it is my understanding) so you are perhaps open up to new actions that really did not exist in the past. The incorporated chipset currently takes care of the USB much closer to the DMA, so I anticipate that the concern is EITHER with the 5/ 3400 chipset or that the concern is with the vehicle driver. Either are very easy to examination, yet they do call for a first resources expense, to make sure that draws.
Below is my thinking why I assume it is the chipset and also not the electronic cameras or vehicle drivers: There are known issues with the Intel PCH (I'm mosting likely to price estimate currently to conserve to and fro clicking:
- USB ports hang with mass and also control website traffic (erratum 7 & Microsoft KB9820911)
- Bogus USB ports will certainly be identified at desktop computer PCH outfitted with 6 USB ports (3420, H55) on the first EHCI controller. This can take place when Air Conditioner power is gotten rid of after getting in ACPI S4. Including Air Conditioner power back and also returning to from S4 might cause non identified or perhaps non operating USB tool (erratum 12)
- Bogus USB ports will certainly be identified at mobile PCH outfitted with 6 USB ports (HM55) on the first EHCI controller. This can take place when Air Conditioner power and also battery are gotten rid of after getting in ACPI S4. Including Air Conditioner power or battery back and also returning to from S4 might cause non identified or perhaps non operating USB tool (erratum 13)
This leads me to think that including a new PCI card will certainly boost efficiency by getting rid of load on the certain USB controller reasoning, yet as an examination attempt relocating both the camera is to the very same USB center (matching piled ports on the motherboard need to suffice) and also see if they show the very same trouble. Bucks to pesos claims that you'll have the EXACT very same concern when you do this.
Nonetheless, I assume it is more probable a concern with UVC vehicle drivers on Linux as a whole with numerous electronic cameras taken care of by the very same controller (as your own is), and also not something details to the equipment. I simply assumed I would certainly start with the equipment first to resolve that certain little bit (given that it is totally feasible maybe liable). Below is a string of relevant URLS:
- http://www.mail-archive.com/[email protected]/msg05235.html
- http://sourceforge.net/projects/mjpg-streamer/forums/forum/739917/topic/2042468 (in fact another thing to take into consideration)
- http://www.lavrsen.dk/foswiki/bin/view/Motion/SupportQuestion2009x04x30x053208 (old)
- http://www.lavrsen.dk/foswiki/bin/view/Motion/SupportQuestion2009x08x04x191406 (comparable trouble, new PCI USB)
- http://lists.berlios.de/pipermail/linux-uvc-devel/2009-May/004806.html (instructions for looking)
- http://www.lavrsen.dk/foswiki/bin/view/Motion/SupportQuestion2009x05x28x183617 (from activity, yet older)
Ok, that suffices babbling in the meantime. Reply remarks?
tl ;dr : get a USB PCI card and also placed one camera on there.