On Wed, 27 Oct 2010, Steve Calfee wrote: > On Sun, Oct 24, 2010 at 1:17 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > The lsusb output for your sound card shows that it doesn't distinguish > > between 44.1 KHz and 48 KHz when listing its bandwidth requirements; it > > asks for the same amount of bandwidth in either case. Â In particular, > > it requires 192 bytes/frame for 16-bit transfers and 296 bytes/frame > > for 24-bit transfers (a frame is 1 ms). Â Don't ask me why the second > > number is 8 bytes larger than it should be -- I don't know. > > > > The information in section 5.11.3 of the USB-2.0 specification shows > > how to compute the amount of USB bus time based on the size of a > > transfer. Â For 192 bytes isochronous OUT this comes to a little over > > 153 us, and for 296 bytes iso OUT it comes to a little over 237 us. > > IN transfers require about 1 us more. Â You can get reasonably close to > > these numbers just by realizing that full-speed USB runs at 12 Mb/s or > > 2/3 us per byte and that bit-stuffing requires all the times to be > > increased by a factor of 7/6 -- and keep in mind that the protocol has > > some overhead. > > > Hi Alan, > > There is something wrong with your calculations. Every ms FS sends > about 12000 bits = 1500 bytes. 90% of this is 1350 bytes. I know this > is approximate, but I have seen fs cameras using the maximum iso xfer > size of 1023, so at least that is possible. You have forgotten about bit-stuffing (section 7.1.9 of the USB-2.0 spec). The hardware inserts an extra 0 bit into the data stream following any six consecutive 1 bits. In the worst case (which we have to assume for bandwidth-allocation purposes) the entire data buffer may consist entirely of 1's, and hence the number of bit times required for transmission must be increased by a factor of 7/6. Thus, even though there is time to send 1350 periodic bytes during a frame, we are not allowed to allocate time for more than 1157 bytes. That's still greater than the maximum packet size of 1023. (Another factor we are ignoring here is that the spec allows the USB bus clock to run slow by as much as 0.25%. That shrinks the maximum allowance a little farther.) > To transfer 6 channels of 3 bytes per sample and 48Khz requires 6 * 3 > * 48 bytes = 864 iso bytes per frame. But these are stereo channels. The total should be 1728 bytes, not 864. Unless I have misunderstood Daniel. > My conclusion is this kind of transfer is legal per the USB spec. > There may be iso bandwidth bugs in Linux, though - especially through > HS hubs, I suggest a test directly connected to his UHCI or OHCI root > hub. If Daniel meant each channel to be mono rather than stereo, then yes -- this would explain why there is no trouble running six channels at 48 KHz when plugged directly into a full-speed controller. The problems when going through a HS hub have yet to be explained. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
