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

[Clemens Ladisch]

Alan Stern wrote:
> On Tue, 13 Aug 2013, Clemens Ladisch wrote:
>>> The difference is that this version tries always to keep a period's
>>> worth of bytes in the USB hardware queue.
>>
>> Having truncated URBs is possible only when URBs are shorter than one
>> period,
>
> No.  URBs are truncated when a full-sized URB would extend at least one
> packet beyond the end of a frame.

This thought was in the context of avoiding too-short queues.  When
there are multiple URBs per period, the queue is long enough anyway.

>> so I think that a queue length of at least two periods, together
>> with a minimum period size, should ensure the isochrounous scheduling
>> threshold.
>
> This depends on how long a period is.

In that patch, a period is guaranteed to be no smaller than the IST.

>> And while we're at it: the default number of packets per URB was chosen
>> before the driver had the ability to estimate the delay from the current
>> frame number; it should now be quite safe to increase it.
>
> I don't understand how this delay estimation is supposed to work, or
> what it is meant to accomplish.  Can you explain?

The "delay" is the difference between the time when a sample is written
by the application and when that sample is actually played, and is
important for things like A/V synchronization.  It depends on
1) the amount of samples already in the ring buffer;
2) any processing done by the driver; and
3) any processing done by the hardware.

Most drivers don't do any processing, and most of the hardware has very
low delays, so it is common for drivers to pretend 2) and 3) are zero.

snd-usb-audio computes 2) from the current number of packets in the
queue, with the progress estimated based on the current frame.  Without
this computation, it was desirable to have short URBs because the delay
would jump by a large amount whenever a URB was completed.


Regards,
Clemens