On Fri, 18 Jan 2008, Jon Smirl wrote: > That's why I was somewhat suspicious that the disconnects are being > caused by software. What happens if the scheduler doesn't have the > data ready in time? Could it cause the reset I am seeing?
You didn't provide enough data to really tell what was happening. Judging from the log info you did provide, it looks as though the host is resetting the hub because of problems with the periodic hub interrupt request. It doesn't look like the hub is actually disconnecting the devices. > 44100 samples * 16 bit * 2 stereo = 1.4112Mb/sec > Three channels is 4.2336Mb into a 12Mb channel. > > But 44100 doesn't divide evenly into 12Mb. So does it get into an > impossible situation of needing to transmit to all three > simultaneously and occasionally trigger the reset? You've got 44.1 32-bit samples per ms. Let's round it up to 45 samples; that makes 180 bytes per ms per output stream. Now according to Table 5-4 in the USB 2.0 spec, the USB bus can accomodate up to 5 Isochronous transfers per ms, even if each transfer contains 256 bytes. So there shouldn't be any problem managing 3 transfers of 180 bytes. However the scheduling is based on the descriptor contents, not on the actual amount of data sent. It would be worthwhile to see the descriptors for the endpoints being used. And of course, this leaves out things like the hub status transfers mentioned above. Even so, bandwidth shouldn't be a problem (those status transfers are certainly not more than 8 bytes). > There is nothing else active on the USB port. The external hub is > plugged into an ohci host. It doesn't sound like a scheduling problem. Besides, if it was the problem would show up immediately, as soon as a program tried to open the channels. It wouldn't show up at random times throughout the day. If you want to find out more about what's going wrong, enable CONFIG_USB_DEBUG and look at the full output (including debugging) from the kernel. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
