Re: Fwd: Isochronos audio
On 9 April 2014 19:53, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 9 Apr 2014, Clemens Ladisch wrote: Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. Alan Stern Hi, Is there any progress on this or is it low priority? BR Russel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Isochronos audio
On 04/16/2014 01:17 PM, Russel Hughes wrote: On 9 April 2014 19:53, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 9 Apr 2014, Clemens Ladisch wrote: Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. Alan Stern Hi, Is there any progress on this or is it low priority? I'll add checking the xhci side of this to my TODO list, (which starts to be quite long already). Might take some before I get to it. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fwd: Isochronos audio
From: Alan Stern ... Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. You also definitely don't want to cancel an isoc urb. Doing so is likely to corrupt the kernel heap. If an isoc urb generates multiple TRB the code allocates a little structure 'per TRB' and links it to the urb. This seems to be done so that it can tell when all the TRB have finished so that it can complete the urb. However if a transfer is aborted they get freed individually, but they were allocated as a single item. I actually suspect the driver doesn't care about the early TRB, so shouldn't need the list at all. David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fwd: Isochronos audio
On Thu, 10 Apr 2014, David Laight wrote: You also definitely don't want to cancel an isoc urb. Doing so is likely to corrupt the kernel heap. If an isoc urb generates multiple TRB the code allocates a little structure 'per TRB' and links it to the urb. This seems to be done so that it can tell when all the TRB have finished so that it can complete the urb. However if a transfer is aborted they get freed individually, but they were allocated as a single item. I actually suspect the driver doesn't care about the early TRB, so shouldn't need the list at all. You've got it backward: We _do_ want to cancel isochronous URBs sometimes. If doing so will corrupt the kernel heap then the driver needs to be fixed. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Isochronos audio
Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Looks like interrupt moderation. What minimum queue length should a driver use to work with all HCs? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Isochronos audio
On Wed, 9 Apr 2014, Clemens Ladisch wrote: Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Looks like interrupt moderation. I don't think so; to me it looks more like a bug. We're already getting one interrupt per ms for the IN endpoint anyway; there's no reason to moderate the one-every-6-ms interrupts for the OUT endpoint. Also, with moderation you'd see several URBs apparently completing at once, but that's not what happened here. In fact, I get the impression that with isochronous URBs A, B, C,... in the queue, xhci-hcd doesn't report the completion of A to the driver until B has terminated, and it reports the completion of B when C has terminated, etc. That's got to be a programming error somewhere. What minimum queue length should a driver use to work with all HCs? What snd-usb-audio is doing right now should be fine. While I'm not acquainted with the detailed operation of xhci-hcd, its requirements should not be any more strict than those of ehci-hcd. And this was a full-speed USB device -- not even high speed, let alone SuperSpeed! Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Isochronos audio
On Wed, 9 Apr 2014, Clemens Ladisch wrote: Alan Stern wrote: The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). By the way, the completion times aren't the only thing that look messed up. The starting frame numbers are also wrong. Here's an extract showing some of the URB completions for the OUT endpoint: 880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264 880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264 880036e15c00 2003768475 C Zo:2:003:1 0:1:1127:0 5 0:0:264 880036e14000 2003774499 C Zo:2:003:1 0:1:1132:0 6 0:0:264 880036e14600 2003779478 C Zo:2:003:1 0:1:1137:0 5 0:0:264 Starting frame number-^ ^ Number of frames-^ If you do the arithmetic, you'll see that the starting frame numbers aren't all what they should be. For example, the 2nd URB starts in frame and lasts 6 frames, so the 3rd URB should start in frame 1117. But instead it starts in 1116. These numbers are clear indications of a bug somewhere in the driver. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Isochronos audio
On Tue, 8 Apr 2014, Russel Hughes wrote: Hi, I put in a new kernel and get the response from uname -r of 3.14.0-031400-generic, apologies for the pedantry I am not that sure what I am doing. The device behaves exactly the same as default Linux kernel, buffer is erratic not stable like USB 2.0 and audio droputs every couple of seconds. The HDMI audio output does not work after installing the new kernel. I captured some data with usbmon but its a big file 4MB so I can email it separately if you are interested but a sample is as below. Maybe it will help with the debugging if I point out that this usbmon trace definitely shows signs of something not working right. The URB completions for the isochronous-OUT endpoint are all delayed by 6 ms or so. Here's the first example: 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 880036e15c00 2003753516 S Zo:2:003:1 -115:1: 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 1537ea16 c9e808b1 f60dd5f1 f7970801 e4fdef09 10fab104 f4e00afb c103fbf6 8800d0237600 2003753520 C Zi:2:003:1 0:1:1123:0 1 0:0:3 4 = 00030b00 The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
