On Mon, 9 Jul 2018, R0b0t1 wrote: > > As far as I can tell, all the transfers did complete properly. I > > didn't find any where the completion line contained an error code. > > > > Is anyone able to comment on this in more detail? I thought it was > supposed to be reported if a transfer did not arrive in time. It depends on what you mean by "arrive in time". If driver on the host waits too long before submitting an URB, nothing special is reported. For example, suppose URB X is submitted and is scheduled for frame 732. After URB X completes, URB X+1 is submitted. But it may already be too late to schedule X+1 in frame 733; in that case it could simply be assigned to some later frame with no error indication. (Or the submission may fail, or the URB may complete almost immediately with a -EXDEV status error; it depends on details of the timing.) On the other hand, if an URB is assigned to some particular frame and the device does not send a reply packet at the right time during that frame, the URB will complete with its iso_frame_desc[] status set to -EXDEV. > > In fact, the pattern here and below indicates that your program submits > > a transfer, waits for it to complete, and then submits the next one. > > That is not a good way to handle isochronous data. You should submit a > > bunch of transfers (five to ten, say), and then submit a new transfer > > whenever an old one completes. That way the request queue is much less > > likely to empty out, and you're less likely to lose data. > > > > Also, a single request can transfer more than one packet of > > isochronous data (although putting multiple packets into a single > > transfer does increase latency). > > > > I updated my C code and now everything works. I think the issue was GC > pauses in Python. That could easily cause problems, given the way your program worked. > What does not work: multiple transfers within an isochronous packet. > More than ~3 transfers results in missing packets (using libusb from > C). If you're still submitting just one transfer at a time, the same phenomenon (GC pauses?) could still cause missing packets. > There is no easy way to implement multiple concurrent transfers with > PyUSB. I may implement it in my C code, but the time between transfers > is relatively large and I see no issues currently. All right, if you say so. The time between frames (for a full-speed device, typical of audio) is one millisecond. That may seem relatively large to you, but in some settings it is considered rather tight. And in fact, the timing window could be a lot shorter than 1 ms. An URB scheduled for frame 732 won't complete until after frame 733 has started. And in order to be scheduled during frame 733, an URB must be submitted not long after the start of that frame -- and certainly before its end. > > I don't understand this. There are two packets both marked for frame > > 1156 and none for frame 1157. That shouldn't happen, but it might be a > > result of the fact that you allow the pipeline to empty out after every > > individual packet. > > > > Can you explain what you mean? The pipeline is the queue of URBs that have been submitted on the host and are waiting to complete. Your program never has a queue length larger than 1, and at times the length drops to 0 (after one transfer completes and before the program submits the next transfer). If you submitted multiple transfers at the start, the queue length would be larger than 1 and it would be most unlikely ever to drop down to 0. The kernel driver treats a queue length of 0 as special for scheduling purposes; to keep a smooth flow of packets with precisely one frame between adjacent entries, it is best to ensure that the queue length is always positive. 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
