Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 5 down vote favorite
2

I am using the Motion package for linux to act as a security system with two Microsoft LifeCam HD-5000 webcams. In general it's working very well but I'm experiencing a weird issue. Every now and then the feed from one cam will exhibit "crosstalk" or "crossover" from the other cam, in sweeping bars, best described in this image (highlighted in red):

WTF?

As you can see, the image is a mixed mess of the inside and the outside camera feeds. I believe this article from Motion's wiki is describing the same issue, however there is no solution there besides:

If you need more than 1 USB camera add extra USB PCI cards to your computer

However that is talking about USB 1.1, and these are USB 2.0 cameras. Also, I do believe this system has two UCB cards and that the cameras are connected to two different USB busses:

root@chef:~# 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
root@chef:~# 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 questions are:

  1. Does anyone know what could cause crossover like this?
  2. Any other troubleshooting suggestions?
  3. I am guessing I will need to ask the developers of Motion for support, so before I do, can anyone confirm that I do have the cameras connected to two different PCI cards as they suggested?
share|improve this question
1  
Does the crosstalk occur when viewing through another program? (like camstream). At least then you'd know it's not motion's fault... – dotjoe Dec 30 '10 at 19:14

1 Answer

up vote 5 down vote

To the first point: USB1.1 was a lot slower than USB2.0, in most cirumstances. Note that devices can still connect at the lower 1.1 speed of 12Mbps instead of the faster 480Mbps, but usually when this occurs it's either because the port is autonegotiating low or it is because one of the two devices is really 1.1. Try disconnecting and reconnecting if you experience this and are sure both are 2.0 and your OS has support for 2.0. (general advice, ya?) ~~ Anyways, that was why they recommended a new card. So that you could use the full USB1.1 speed per individual camera since the PCI bus is way faster than USB1.1. But with 2.0 that's not necessary. [dead horse flogged, going on to next topic]

Now onto your device specifically. You've a Core i5 by most ostensible metrics, namely: Intel 5 / 3400 series PCH and 82801 PCI bridge. (side note: confirmed that he has a Dell Core i5) This particular PCH is also code-named Ibex Peak. You no longer have an independent southbridge (as it is my understanding) so you're possibly open to new behavior that didn't exist before. The integrated chipset now handles the USB much closer to the DMA, so I expect that the issue is EITHER with the 5/3400 chipset or that the issue is with the driver. Either are easy to test, but they do require an initial capital outlay, so that sucks.

Here's my reasoning why I think it's the chipset and not the cameras or drivers: There are known issues with the Intel PCH (I'm going to quote now to save back and forth clicking:

  • USB ports hang with bulk and control traffic (erratum 7 & Microsoft KB9820911)
  • Bogus USB ports will be detected at desktop PCH equipped with 6 USB ports (3420, H55) on the first EHCI controller. This can happen when AC power is removed after entering ACPI S4. Adding AC power back and resuming from S4 may result in non detected or even non functioning USB device (erratum 12)
  • Bogus USB ports will be detected at mobile PCH equipped with 6 USB ports (HM55) on the first EHCI controller. This can happen when AC power and battery are removed after entering ACPI S4. Adding AC power or battery back and resuming from S4 may result in non detected or even non functioning USB device (erratum 13)

This leads me to believe that adding a new PCI card will improve performance by removing load on the particular USB controller logic, but as a test try moving both the camera's to the same USB hub (matching stacked slots on the motherboard should be sufficient) and see if they exhibit the same problem. Dollars to pesos says that you'll have the EXACT same issue when you do this.

However, I think it's more likely an issue with UVC drivers on Linux in general with multiple cameras handled by the same controller (as yours is), and not something specific to the hardware. I just thought I would start with the hardware first to address that particular bit (since it's entirely possible it could be at fault). Here's a string of related URLS:

Ok, that's enough rambling for now. Reply comments?

tl;dr: get a USB PCI card and put one camera on there.

share|improve this answer
Thanks! That's a very thorough answer. The part about the integrated chipset is pushing the limits of my understanding of the hardware, but it makes sense. As for USB 1.1 vs 2.0, I'm almost positive the devices are connected at full 2.0 speed because lsusb says "480M", that's USB2.0 speed, right? – Josh Dec 21 '10 at 23:22
1  
Yes, that's USB2.0 speed, and while you do have several ports you still just have the one controller and it's all funneling back through the one port, as it were, to the DMA spot. Remember it's a tree, there's always one root device for the USB (up to the level of a PCI or other bridge controller, then it gets onto the parallel bus of the backend of the system) So if you add a PCI USB card then you'll have two "usb trees" logically, which is what the point of the recommendation of the other card was ;) – jcolebrand Dec 21 '10 at 23:51
Ah, OK, so even though lspci lists two USB cards, and lsusb lists two USB busses, they're really all just one? – Josh Dec 22 '10 at 15:08
As I understand the situation, yes. However, I've been known to be wrong before. I've installed USB PCI cards before that read as more than one to the system, with only one physical card. ~ I've also seen video cards with their own PCI bridge to give them better internal bandwidth for multiple monitors, which causes headache when you have a motherboard with a PCI bridge, and a chipset with a southbridge component. You think "slots, card, work" but noooo, hardware is a special beast, and needs TLC. – jcolebrand Dec 22 '10 at 15:41
To be clearer on the last PCI bridge concern: The average system expects to find one PCI bridge, at most, after the southbridge. So the (Windows at least) kernel allocates enough whatever to handle one PCI bridge. If a second one is encountered, the kernel can't deal with it, so it ignores it as faulty hardware. So on a system with more than PCI bridge, if you have a Windows machine at least, you have to have a specific patch for that system. Interesting stuff that. This is a lesson to the Unix/Linux guys, let your board drivers be recursive, it's ok. ;) – jcolebrand Dec 22 '10 at 16:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.