Alan Stern wrote: > On Thu, 25 Jul 2013, James Stone wrote: >> 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). In ALSA, the number of frames per period is a constant integer, and Jack requires it to be a power of two. (Where "frame" is an audio frame, and "period" is the interval between interrupts reported to user space.) > 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 With a sample rate of 44100 Hz and a packet rate of 8000 Hz, there should be about 5.5 samples per packet. With a period size of 64 audio frames, this results in about 11.6 packets per period. The driver does not completely fill URBs to ensure that interrupts happen at period boundaries. > 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. The feedback data is not measured in "real Hz" (wall clock time) but relatively to the 8 kHz bus clock. Furthermore, it does not show the device's internal clock but the rate at which the device wants to receive frames; this can be higher at the beginning of a stream if the device has an empty FIFO and wants to fill it up. Regards, Clemens -- 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
