On Fri, Jul 26, 2013 at 11:43 PM, James Stone <jamesmstone@xxxxxxxxx> wrote: > 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 Apologies - that was with 3 periods/buffer. 2 periods/buffer attached. James
Attachment:
1.mon.out
Description: Binary data
