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