On Sat, 14 Jul 2018, R0b0t1 wrote: > I implemented your recommendation and I still have issues receiving > multiple isochronous packets as part of one scheduled transfer. The > maximum is now 5 or 6 in a row, as opposed to 2 or 3. Any more and > there is stuttering. It does not matter how deep I make the transfer > ring buffer. There are different effects based on how many isochronous > packets I schedule at once (slight buzzing, lots of buzzing, ear-bleed > inducing buzzing). > > This may be okay as I can still get it working. However I was hoping > to test the throughput and latency of receiving a few hundred > milliseconds of audio at one time as opposed to constant smaller > transfers. Windows prefers the former, I'd like to know if there is > any reason why. (It probably related to the kernel's structure and > irrelevant when on other OSes - I get consistently better throughput > on Linux without trying.) > > I also expect operation to proceed smoothly no matter how many > transfers are scheduled. If I am double (or triple, or more) buffering > packet scheduling what else could there be?
I don't know. The best way to track down problems is more usbmon tracing. > >> 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. > > > > Thanks for the clarification. That is a pretty compelling reason to > keep a ring buffer. I was hoping to keep the code as simple as > possible. My program does actually manage to keep the transfer queued > before the device sends so I am still confused, especially since the > problem persists. Again, use usbmon to make sure your assumptions are correct. If usbmon shows that everything is working correctly on the host side then the problem has to lie in the device. 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
