Of course you got a lot more output. That's because the audio-in worked under 3.5 but not under 3.8. It generated something like 7 times as much data from usbmon as the audio-out, partly because of the ridiculously low latency.
I assume the 3.8 usbmon trace was also done with jack set to 256. Can you provide a short trace (1000 lines would be more than enough) showing jack at 512? Part of the difficulty here is that I don't understand your terminology. What do you mean by a "frame" and a "period"? You wrote above than 256 "frames/period" gives a round-trip time of 21.3 ms, implying that one "frame" is 21.3 ms / 512 = 41.6 us. Where does that number come from and what does it mean? Is it a coincidence that this value is 1 / (24 KHz)? For that matter, what sampling parameters did you use for the audio-in? That is, bits per data value, data values per sample (i.e., mono vs. stereo), and samples per second? Finally, it's worth mentioning that what I wrote earlier wasn't quite right. For the audio-in channel, the total pipeline length was indeed 1 ms. But for incoming data, the latency is the time between transfers, not the pipeline length, so the latency was actually 125 us. Neither value is at all close to your implication that 256 "frames/period" gives a round-trip time of 10.7 ms. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1191603 Title: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
