[alsa-devel] Buffer size for ALSA USB PCM audio
stern at rowland.harvard.edu
Tue Aug 27 18:50:21 CEST 2013
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. :-)
More information about the Alsa-devel