On Tue, 16 Jul 2013, James Stone wrote: > 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.
Usbmon traces, please (for 3.8 only; I'm willing to believe that 3.5 works okay). It's difficult to predict the final effect of the parameters you supply to JACK, because the ALSA layer imposes its own set of requirements on them. Also, changing the ALSA layer to use a larger minimum pipeline length might end up fixing all these problems. I'm sure that with the current code at 64 frames/period, the hardware ends up skipping some frames, even though the effect may not be audible. > Could there be any other changes to the kernel between 3.5 and 3.8 > that might be affecting this? I don't know. But don't forget also that some of the behaviors you see now may be a result of the first patch from Clemens (the one that fixes the problem of the ridiculously large maxpacket values). That patch may not apply cleanly to the 3.5 kernel, but if it does, finding out what effects it has could be interesting. > 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. No, it's not necessary. I know where in ehci-hcd the relevant changes occurred. 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
