On Thursday 02 February 2006 9:23 pm, Jamaal Speights wrote: > Hello, > > I'm having a problem using two usb PVRs that work under the Video for Linux > Two device driver system. The device i'm using is a KWorld USB PVR which > uses the em28xx drives. When I input the two devices udev creates > /dev/video0 and /dev/video1. I can use each device using mplayer > individual, however using USBview I notice that the bandwidth allocated to > the FIRST USED device is %60 percent.
That math seems a little odd, if the biggest high bandwidth transfer is using only 964 bytes (times three) per packet. There are no other USB devices using periodic transfers, I take it? No hubs, etc? Plus, remember that any bandwidth statistics shown through usbfs (and hence usbview) are just approximations that reflect average usage. It might help to forward the /sys/class/usb_host/usb_host1/periodic schedule dump for your EHCI controller, while you're using one of those devices (and seeing "60%"). That should be informative. > So whenever I try using both devices > at the same time, the first device I call with mplayer, linux will allocate > %60 percent of the USB 2.0 bandwidth to /dev/video0 (in this example). > However when I try capturing from the second device I get "Not enough space > left on device" because the second device probably wants to allocate 60% > bandwidth as well. I've been working with *Markus Rechberger *who is one of > the main em28xx v4l2 driver authors. From his knowledge he states that its > most likely a usb subsytem issue with bandwith allocation. Below are the > technical details Maybe ... notice how tables 5-5 and 5-8 say that one peak bandwidth transfer (three 1-KB packets per microframe) takes up 42% of the bandwidth, of which only 80% may be reserved for such periodic usage. (So while two transfers may physically fit, as shown in those tables, they're not permitted because they'd exceed the bandwidth available for periodic transfers.) Of course, three 964 byte packets should be just _under_ that limit, allowing the use of two such transfers... and I can't see an additional one-byte transfer making trouble. So you might be right that the math in drivers/usb/core/hcd.c for high speed calculations is a bit off. - Dave > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 6 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 255 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0001 bytes 1 once > bInterval 11 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 1 > Transfer Type Isochronous > Synch Type None > Usage Type Data > wMaxPacketSize 0x13c4 bytes 964 three times > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 bytes 512 once > bInterval 1 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
