On Thu, Jul 25, 2013 at 10:24 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Thu, 25 Jul 2013, James Stone wrote: > >> On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern <st...@rowland.harvard.edu> >> wrote: >> > On Thu, 25 Jul 2013, James Stone wrote: >> > >> >> > Please try the patch from here: >> >> > >> >> > http://marc.info/?l=linux-usb&m=137476385206265&w=2 >> >> > >> >> > instead of the one I sent to you yesterday. I think it will fix this >> >> > problem. >> >> > >> >> > Alan Stern >> >> > >> >> >> >> Perfect! All fixed! >> > >> > Can you provide a usbmon trace showing the start of a session using the >> > new patch? >> > >> > Alan Stern >> > >> >> Sure - will send off list. The only slight difference I can see is >> that maybe the 3.10 uses slightly higher CPU load than 3.5 at the >> ridiculously low latency of 64 frames/period duplex. > > With the new patch, what you actually get is 44.1 frames/period (on > average). That's quite sustainable. > > However, something's not working right. The number of packets in each > playback URB changes each time the URB is reused! That's not supposed > to happen. The number of packets should remain fixed while the number > of samples in each packet changes, based on the feedback info. > > I don't get it. The usbmon trace shows three URBs, and the number of > packets goes like this: > > 8 8 8 8 4 8 4 8 3 8 4 8 4 8 3 8 4 8 3 8 4 8 4 8 > etc... > > I'm at a complete loss. It's not caused by confusion on the feedback > endpoint; in fact the driver doesn't change this number anywhere once > it has been set up. What's going on? > > James, please apply the diagnostic patch below on top of everything > else. It will write entries into the kernel log which hopefully will > pin down where this number gets changed. > > Another problem, not necessarily a bad one: The feedback data from the > sound device indicates that its internal clock is actually running at > 45168 Hz, even though it claims to be running at 44100. >
OK - here is the output: Jul 25 23:58:46 blueberry kernel: [ 24.440327] Actions configured Jul 25 23:59:00 blueberry kernel: [ 39.070484] A urb ffff88002e02ca00 cnt 2 Jul 25 23:59:00 blueberry kernel: [ 39.071467] B urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.071473] C urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.071479] A urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.072465] B urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.072471] C urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.072477] A urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.072706] B urb ffff88002e02ca00 cnt 2 Jul 25 23:59:00 blueberry kernel: [ 39.072711] C urb ffff88002e02ca00 cnt 2 Jul 25 23:59:00 blueberry kernel: [ 39.072717] A urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.073700] B urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.073702] C urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.073704] A urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.074754] B urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.074765] C urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.074773] A urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.075703] B urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.075709] C urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.075715] A urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.076702] B urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.076707] C urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.076713] A urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.077711] B urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.077718] C urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.077724] A urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.078700] B urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.078705] C urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.078711] A urb ffff88002e02ca00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.079700] B urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.079705] C urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.079711] A urb ffff8800c9758a00 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.080747] B urb ffff8800c9758400 cnt 8 Jul 25 23:59:00 blueberry kernel: [ 39.080759] C urb ffff8800c9758400 cnt 8 It only wrote this the first time I started jackd. The following times, I just got this: Jul 25 23:59:41 blueberry kernel: [ 79.775595] ieee80211 phy0: rt61pci_txdone: Warning - TX status report missed for entry 12 Jul 26 00:01:20 blueberry kernel: [ 178.994157] ieee80211 phy0: rt61pci_txdone: Warning - TX status report missed for entry 15 Jul 26 00:01:24 blueberry kernel: [ 182.778798] ieee80211 phy0: rt61pci_txdone: Warning - TX status report missed for entry 26 Jul 26 00:01:27 blueberry kernel: [ 185.970062] ieee80211 phy0: rt61pci_txdone: Warning - TX status report missed for entry 6 Jul 26 00:01:29 blueberry kernel: [ 188.097538] ieee80211 phy0: rt61pci_txdone: Warning - TX status report missed for entry 28 .. I know there is some talk of wireless functionality interfering with realtime audio, but not sure this is really related. -- 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
