At 32 frames/period (reported round-trip latency 1.33ms), it starts up but there are too many xruns for it to be usable. James On Thu, Aug 29, 2013 at 4:00 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 29 Aug 2013, James Stone wrote: > >> On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Wed, 28 Aug 2013, Clemens Ladisch wrote: >> > >> >> Sorry, what I said applies more to explicit sync endpoints. When using >> >> implicit sync, a playback URB is submitted for each completed capture >> >> URB, with the number of samples per packet identical to the >> >> corresponding capture packet, so the parameters must be identical. >> > >> > Got it. Below is an updated patch. >> > >> > James, the problem you encountered was most likely a result of the >> > faulty treatment of capture endpoints that Clemens pointed out. It was >> > quite obvious in the usbmon traces that the unpatched driver used 8 >> > packets per URB whereas the patched driver used 22. This updated patch >> > should fix that problem. >> > >> >> Works fine. With this, it is possible to get clear playback at 64 >> frames/period too. With vanilla 3.10.9, there was some glitchy >> distortion to the sound at that latency, so this seems to be an >> improvement. > > That's good. What happens if you push frames/period even lower? > > Daniel and Eldad, more testing of the most recent proposed patch would > be welcome. > > 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
