On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > cases URBs with typically 5 isoc frames of 192 bytes > > > length are queued. The wMaxPacketSize of the > > > endpoint is 196 bytes. A USB analyzer connected > > > via musb and hub revealed that musb breaks > > > the 192 byte frames into two parts, one 188 byte > > > and one 4 byte frame, ie. a 192 byte OUT transaction > > > produces the following token sequence: > > > > > > SPLIT > > > OUT > > > DATA0 188 bytes > > > SPLIT > > > OUT > > > DATA0 4 bytes > > > > That is correct behavior when a full-speed device is connected to a > > high-speed hub. > > Is it? I would expect a single 192 byte packet here, breaking > it in two doesn't make sense even if the hub would be able > to reassemble the parts. My recollection of the SPLIT mechanism > is to free up the HS bus between FS send and FS ACK for other > transactions on other hub ports, not to split the data packets. You have to get down into the gritty details. They are explained in the USB spec, if you're curious. Basically, the idea is that the transfer gets broken up into pieces, each of which is more or less capable of fitting in a single microframe (125 us = 188 bytes of FS data, approximately). As far as I can tell, it was done this way so as to minimize the amount of data a hub would have to store and forward -- a bad tradeoff since it increases driver complexity while saving only a few KB of storage (a completely negligible amount nowadays). > > Perhaps the values in the DATA packets are wrong. The best way for you > > to tell is to move the bus analyzer downstream from the hub and then > > compare the values you see in the packets with the audio data being > > played. > > The ALSA driver should be unaware of the hub and > send the same data, right? That's right. 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
