On Wed, Mar 25, 2015 at 10:11:27AM -0400, Alan Stern wrote: > On Wed, 25 Mar 2015, Peter Chen wrote: > > > > > How do you know the frame has filled already at that time? The software > > > > makes sure it fills frame in time before next time frame? > > > > > > I'm not sure I understand the question. > > > > > > The USB analyzer log showed something like this (this is a rough > > > approximation because I didn't keep the original analyzer output file): > > > > > > Timestamp Transaction > > > s.mmm uuu > > > ----------------------------------- > > > 0.000 000 SOF > > > 0.000 030 Isoc OUT > > > 0.000 091 Isoc OUT > > > 0.000 162 Isoc OUT > > > 0.000 224 Isoc OUT > > > 0.001 000 SOF > > > > > > In this example, there are 4 OUT transfers taking about 290 us and then > > > nothing else for the rest of the frame. > > > > > > I also know, from looking at the "periodic" file in the EHCI debugfs > > > directory, that each frame was linked to 8 siTDs: > > > > > > siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 > > > siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 > > > siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 > > > siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 > > > siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 > > > siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 > > > siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 > > > siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 > > > > > > > I did not debug too many for Host ISOC, I just want to make sure the > > siTD is ready before the controller read it? > > Yes, all the siTDs were ready before the controller read them. I know > because it worked perfectly when I used a high-speed hub instead of a > full-speed hub. > > > Does it fail at the beginning or running several cycles? > > The isochronous streams did not all start at the same time. First one > isoc-OUT stream started, then the second stream, then the third stream, > then the fourth stream. After that, the isoc-IN streams started, one > by one. > > The controller worked okay up until the time the isoc-IN streams began. > Before that, it transmitted the OUT packets correctly. After the > isoc-IN streams started, the controller sometimes transmitted only the > four OUT packets (like in the example above), sometimes a mixture of > OUT and IN packets, and sometimes only one or two IN packets. The > behavior was very erratic. > Hi Alan, I tried to your case today, but it seems full speed hub with siTD has some problems with latest greg's next tree, I use UAC2 with configfs for audio device, high speed hub works ok. The commands: aplay -D hw:1,0 audio32k16M.wav arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav The corresponding failure logs: [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth -- Best Regards, Peter Chen -- 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
