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
Fwd: Isochronos audio
-- Forwarded message -- From: Russel Hughes russel.hug...@gmail.com Date: 6 April 2014 11:32 Subject: Isochronos audio To: linux-usb linux-usb@vger.kernel.org Can you describe the actual problem ? How can you trigger it ? What are you doing when the problem arises ? Do you hear audio glitches or does the device disconnect ? Do you have a crash ? Does the *same* device work on other setups ? Try to capture a usbmon trace of the failure, that's likely to help. -- 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. sudo cat /sys/kernel/debug/usb/usbmon/2u /tmp/1.mon.out Thanks Russel 8800d0230400 2003746485 C Zi:2:003:1 0:1:1116:0 1 0:0:3 4 = 00030b00 8800d0230400 2003746493 S Zi:2:003:1 -115:1:1116 1 -18:0:3 4 8802115e9540 2003746499 C Ii:2:003:3 0:32 2 = 0002 8802115e9540 2003746514 S Ii:2:003:3 -115:32 2 880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 880036e14600 2003747556 S Zo:2:003:1 -115:1:1106 5 -18:0:264 -18:264:270 -18:534:264 -18:798:264 -18:1062:264 1326 = b40e4abb e343b295 4cb72848 bc8d42bd 7341c10b 3ec4943b c2883dc8 9737cc17 8800d0230100 2003747563 C Zi:2:003:1 0:1:1117:0 1 0:0:3 4 = 00030b00 8800d0230100 2003747564 S Zi:2:003:1 -115:1:1117 1 -18:0:3 4 8800d0237900 2003748552 C Zi:2:003:1 0:1:1118:0 1 0:0:3 4 = 00030b00 8800d0237900 2003748561 S Zi:2:003:1 -115:1:1118 1 -18:0:3 4 8800d0237600 2003749520 C Zi:2:003:1 0:1:1119:0 1 0:0:3 4 = 00030b00 8800d0237600 2003749526 S Zi:2:003:1 -115:1:1119 1 -18:0:3 4 8800d0230400 2003750493 C Zi:2:003:1 0:1:1120:0 1 0:0:3 4 = 00030b00 8800d0230400 2003750498 S Zi:2:003:1 -115:1:1120 1 -18:0:3 4 8800d0230100 2003751518 C Zi:2:003:1 0:1:1121:0 1 0:0:3 4 = 00030b00 8800d0230100 2003751523 S Zi:2:003:1 -115:1:1121 1 -18:0:3 4 8800d0237900 2003752501 C Zi:2:003:1 0:1:1122:0 1 0:0:3 4 = 00030b00 8800d0237900 2003752506 S Zi:2:003:1 -115:1:1122 1 -18:0:3 4 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 8800d0237600 2003753521 S Zi:2:003:1 -115:1:1123 1 -18:0:3 4 8800d0230400 2003754492 C Zi:2:003:1 0:1:1124:0 1 0:0:3 4 = 00030b00 8800d0230400 2003754494 S Zi:2:003:1 -115:1:1124 1 -18:0:3 4 8800d0230100 200371 C Zi:2:003:1 0:1:1125:0 1 0:0:3 4 = 00030b00 8800d0230100 2003755560 S Zi:2:003:1 -115:1:1125 1 -18:0:3 4 8800d0237900 2003756552 C Zi:2:003:1 0:1:1126:0 1 0:0:3 4 = 00030b00 8800d0237900 2003756561 S Zi:2:003:1 -115:1:1126 1 -18:0:3 4 8800d0237600 2003757557 C Zi:2:003:1 0:1:1127:0 1 0:0:3 4 = 00030b00 8800d0237600 2003757565 S Zi:2:003:1 -115:1:1127 1 -18:0:3 4 880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 880036e14000 2003758507 S Zo:2:003:1 -115:1:1116 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 1761e712 8ded1cce e21323ec 1264ec08 caf607e0 f7ff1500 0823f703 28fc1409 8800d0230400 2003758511 C Zi:2:003:1 0:1:1128:0 1 0:0:3 4 = 00030b00 8800d0230400 2003758512 S Zi:2:003:1 -115:1:1128 1 -18:0:3 4 8800d0230100 2003759550 C Zi:2:003:1 0:1:1129:0 1 0:0:3 4 = 00030b00 8800d0230100 2003759559 S Zi:2:003:1 -115:1:1129 1 -18:0:3 4 8800d0237900 2003760554 C Zi:2:003:1 0:1:1130:0 1 0:0:3 4 = 00030b00 8800d0237900 2003760563 S Zi:2:003:1 -115:1:1130 1 -18:0:3 4 8800d0237600 2003761552 C Zi:2:003:1 0:1:1131:0 1 0:0:3 4 = 00030b00 8800d0237600 2003761561 S Zi:2:003:1 -115:1:1131 1 -18:0:3 4 8800d0230400 2003762512 C Zi:2:003:1 0:1:1132:0 1 0:0:3 4 = 00030b00 8800d0230400 2003762515 S Zi:2:003:1 -115:1:1132 1 -18:0:3 4 880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264 0:264:270 0:534:264 0:798:264 0:1062:264 1326 880036e14600 2003763519 S Zo:2:003:1 -115:1:1121 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 26acd81f 9fe02ac2 d423c1db 2f70d027 1fd82b7f d424d5da 28b0d623 35dc2e61 8800d0230100 2003763524 C Zi:2:003:1 0:1:1133:0 1 0:0:3 4 = 00030b00 8800d0230100 2003763526 S Zi:2:003:1 -115:1:1133 1 -18:0:3 4 8800d0237900 2003764553 C Zi:2:003:1 0:1:1134:0 1 0:0:3 4 = 00030b00 8800d0237900 2003764562 S
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
