On Tue, 27 Aug 2013, Clemens Ladisch wrote: > There is no reasoning about capture endpoints. > > The driver cannot control how many samples actually end up in a capture > packet, so it is possible that URBs end up being one USB frame longer > than a period, in which case the ALSA period interrupts will accumulate > delays of up to one period, or that URBs end up being one USB frame > shorter than a period, in which case the ALSA period interrupt will be > delayed to the end of the _next_ URB. > > The current algorithm uses very short capture URBs to ensure that _some_ > URB is completed as soon as possible after a period ends. > > Your patch makes things worse for running jackd at lower latencies > because playback and capture period interrupts are expected to be more > or less synchronous (jackd waits for both interrupts before acting on > one period). With only two periods per buffer and the capture period > interrupt randomly delayed by up to one period, the time available for > processing one period is reduced to zero. > > I'd suggest to keep the old calculation for capture URBs. It would > make sense to use longer capture URBs only if the period size is > relatively large. Okay. What about playback endpoints with implicit sync? The current driver treats them the same as capture endpoints. Is that really the right thing to do? > Note: for capturing, the number of URBs has no effect on latency and > just reduces the risk of overruns, so it is desirable to make the queue > as long as possible (for a given URB length). Sure. It looks like the only limit that will matter here is MAX_URBS. > > Not having heard any responses to the patch posted last Wednesday, > > Sorry, my #patches / free_time quotient is rather large. Me too. And don't forget bug reports. :-) Alan Stern -- 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
