Devin Heitmueller wrote: <snip> > The issue occurs with various different drivers. Basically the issue > is the device attempts to reserve a certain amount of bandwidth on the > USB bus for the isoc stream, and in the case of analog video at > 640x480 this adds up to about 200Mbps. As a result, connecting > multiple devices can result in exceeding the available bandwidth on > the USB bus. > > Depending on your how many devices you are trying to connect, what > your target capture resolution is, and whether you can put each device > on its own USB bus will dictate what solution you can go with. Hi all, So I felt like doing a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Best regards, Jelle de Jong -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
