Alan Stern wrote:
All the difficulty arises from the fact that we don't know beforehand how many URBs will constitute an ALSA period since for playback endpoints, the URB sizes can vary. [...] the number of URBs per period is fixed, and the number of packets in each URB is adjusted during playback so that all the URBs end up having roughly the same number of frames. [...] The parameter calculation now ends up being the same for both recording and playback endpoints. This may seem odd, but it follows from the reasoning above.
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.
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).
Not having heard any responses to the patch posted last Wednesday,
Sorry, my #patches / free_time quotient is rather large.
Regards, Clemens