On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge <hegge@xxxxxxxxxxx> wrote: > 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 Thanks for this info. I just tried it out, and the device starts up much more cleanly - no flashing lights etc. at longer latencies. It will still not start jackd at 256 frames/period, but this might need Clemen's do not trust too-big wMaxPacketSize values patch added.. Will report back. 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
