On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote: > On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 19 Jul 2013, James Stone wrote: > > > >> > The questions now are: > >> > > >> > Why are the same requests sent over and over again? > >> > > >> > Why does the ALSA driver attempt to set the clock frequency > >> > while the clock is actively in use? > >> > > >> > Has this behavior changed since the 3.5 kernel? > >> > > >> > >> Well, I think these requests may correspond to the lights flashing on > >> and off on the front of the device. When starting the device in 3.5 at > >> 256 frames/period (duplex), the lights flash on and off 2 times, in > >> the current patched 3.8 version I have been using, the device lights > >> flash on and off 4 times before starting jack with exactly the same > >> settings - so it seems for some reason, the requests are going through > >> multiple times on the 3.8 kernel but not on 3.5. I will send a 3.5 > >> usbmon trace of a successful start off list (plus the same for 3.8?) > >> if it would be useful. > > > > I don't know -- it's up to Clemens. > > > > Alan Stern > > > > Hi Alan, > > Just tried a few old kernels, and it seems that the bug I am > experiencing was introduced at the start of 3.7 - kernel 3.6.11 is > fine, and all the 3.7 series kernels are broken. So it seems it is not > the updated ehci usb code that is directly responsible for the > realtime audio problem. I have been trying the kernels from: > http://kernel.ubuntu.com/~kernel-ppa/mainline/. Any suggestions on how > to further zoom in on the culprit commit? Can you reproduce the problem on a 3.10 kernel? I suspect this is related to the commit 61a70950 "ALSA: usb-audio: Move configuration to prepare" in kernel 3.7, which introduced calls to set sample rate in prepare, even if the sample rate is unchanged. It looks like jackd calls prepare twice when starting, which is consistent with two get rate/set rate sequences. The unnecessary set rate shouldn't happen with kernel 3.10, as it includes fa92dd77 "ALSA: usb - Avoid unnecessary sample rate changes on USB 2.0 clock sources", which says in the commit message: "The Scarlett 2i2 seems to take almost 500 ms to set the sample rate, even if the clock is currently set to that value. This patch speeds up prepare of the device, by avoiding setting the clock to something it already is." Torstein -- 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
