On Mon, Mar 30, 2015 at 01:41:29PM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > The log between hub and soundcard shows this: > > > > SOF > > OUT > > DATA0 185 byte with CRC error > > OUT > > DATA0 4 bytes > > Which is totally wrong, of course. Yes, my assumption is that the receiption of the 4 byte packet truncates the 188 byte packet in the hub. > That is not good. The two Start SPLIT transactions are not supposed to > occur in the same microframe. The second transaction should have > occurred during microframe 1194.1. That could easily confuse the hub. ... > This data is all for frame 1193, not 1194 as in the high-speed trace. > Were the two traces made at the same time? Nope, I'm glad to have access to _one_ USB analyzer. The packet sequence is very repetitive, I chose sequences with the same packet number from both logs but they do not actually correspond. That also makes it difficult to compare the packet's data contents although it should match up since the same audio clip is played in both cases. > > (The Total Phase analyzer does not allow text export or copy&paste, > > so I had to reproduce manually. Apparently it does not show > > OUT SPLIT Comlete and IN SPLIT Start.) > > It does show isoc-IN Start SPLITs if you look closely. It doesn't show > isoc-OUT Complete SPLITs because there is no such thing. OK, it shows Start -> NYET -> Complete, once I figured out how to read the trace I can see it. > > While it seems permissible by the USB spec to split the payload, > > Not permissible -- required! See paragraph 2a in section 11.18.4 of > the USB-2 spec. > > > I don't understand the reason to do so. I mean the payload has > > to be smaller than the wMaxPacketSize of the EP, and the > > wMaxPacketSize of a FS EP is always smaller than the max > > size of an HS Isoc data packet? I must be missing something... > > It's done this way to minimize the amount of data buffering needed in > the hub's Transaction Translator. Full-speed transactions are broken > up into microframe-sized pieces, and the TT is required to store only a > few of these pieces. > > Since it's not possible to transfer more than 188 bytes over a > full-speed link in 125 us (one microframe), transfers are broken up > into pieces that are 188 bytes or the remainder of the transfer, > whichever is smaller. The same thing happens with Complete SPLITs for > long isoc-IN transfers. > > > Apparently the hubs cannot cope with this sequence, does it > > mean all four hubs which were tested are buggy? > > Judging by your high-speed log, it looks like the host controller is > not sending out the Start SPLIT transactions the way it should. Yes, it happens consistently that the host send two SPLIT OUT packets in the same microframe. So that explains the cause of the issue, the question is now if there is a workaround, but my expectations are low since the musb split packet handling is all done in hardware. Thanks, Johannes -- 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
