On Wed, Jul 24, 2013 at 12:23 AM, James Stone <jamesmstone@xxxxxxxxx> wrote: > 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 Ok - this does seem to be a vast improvement over 3.8.x (and even, in some ways the 3.6x series) - with the addition of Clemen's patch. However, very low realtime latencies (which seemed to be somewhat possible - 64 frames/period or lower - in the 3.6x series) will no longer work properly. 128 frames/period looks fairly usable. Will continue with bisect to see if I can discover anything else. -- 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
