On Fri, Jul 26, 2013 at 7:54 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 26 Jul 2013, Clemens Ladisch wrote: > >> 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.) >> >> 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. > > Oho! I missed all that period_elapsed stuff in prepare_playback_urb()! > But you don't do the same thing for recording URBs -- presumably > because you can't tell in advance how many samples the device will > send. > > This makes the calculation of the number of URBs more complicated. > Revised patch below. > > James, can you try this out and send me the usbmon trace? At 64 > frames/period this should end up using 4 URBs, which is the minimum > requirement if there are no more than 8 packets per URB and an > incompletely filled URB can contain as few as 1 packets. With this > patch, there should be no difficulty going down to 32 or maybe even 16 > frames/period. > > Here you go.. (attached). This is at 64 frames/period. James
Attachment:
1.mon.out
Description: Binary data
