On Wed, Jul 24, 2013 at 2:42 AM, James Stone <jamesmstone@xxxxxxxxx> wrote: > 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. Ok -from the bisect, the problem of not being able to get to sub 64-frames per period starts with: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112 Could this be the offending deletion? http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/sound/usb/endpoint.c?id=fc600432cd23e35c85de2ff4468d816d6938a112 ?? 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
