On Tue, Jul 16, 2013 at 7:36 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 15 Jul 2013, James Stone wrote: > >> >> James, did you ever provide a usbmon trace for 3.8 doing playback only >> >> and using 64 frames/period? I don't recall seeing any. It might help. >> >> >> > >> > OK - will send it to you off-list. > > I got it. It explains a lot. > > The audio-out stream uses a pipeline of only 2 URBs. The URBs start > out alternating between 8 and 7 packets apiece. This yields a total > latency around 1.9 ms (equivalent to 2 periods of about 41 frames at > 44.1 KHz), which is smaller than I would expect (2 periods of 64 frames > works out to 2.9 ms). > > Anyway, this sort of works. Every so often (roughly at intervals of 15 > ms) there is an underrun. Evidently the computer's EHCI hardware > sometimes requires URBs to be submitted more than 7 microframes in > advance. This means that the minimum safe pipeline length is 2 ms, and > a little more would be better. Indeed, there was one example in the > usbmon trace with an IRQ latency over 65 us, which is half a > microframe. (Alternatively, a pipeline containing 3 URBs with 5 > packets each should be okay, although it would cause increased > interrupt overhead.) > > After a second of this, the URBs suddenly changed. They began to > alternate between 7 and 5 packets; one of them had only 4. I have no > idea why this happened. It led to a situation where ehci-hcd refused > to accept an URB submission because it wasn't far enough in advance, > and at that point everything came to a halt. > > Try the patch below; it should eliminate the "everything stops" > problem. But it will not do anything about the ongoing underruns. To > fix that, the latency has to be increased. Or rather, the latency > between the ALSA and USB stacks needs to increase to match the > latency expected by JACK. A pipeline of 2.9 ms (23 packets total) > ought to be okay, whereas a pipeline of 15 packets -- what you're > getting now -- is too short. > > And if the pipeline was long enough, the patch below wouldn't be > needed. > Thanks. The patch allows jack to now start at (playback only) 64 frames/period. It doesn't work with 32 frames/period though (I think you predicted this). This is still a regression from 3.5.0-28, which will work with 8 frames/period for playback only. Furthermore, jack won't start in duplex at 128 frames/period. It doesn't (yet) tempt me to use the 3.8 series kernels for proper audio work. Could there be any other changes to the kernel between 3.5 and 3.8 that might be affecting this? I was also wondering if it would be worth me trying to pinpoint which commit to the kernel caused this regression? If this is worthwhile, pls give some approximate instructions as to how to proceed. Best wishes, James -- 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
