[alsa-devel] Buffer size for ALSA USB PCM audio

[Clemens Ladisch]

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