Jassi Brar wrote: > On Wed, Sep 5, 2012 at 5:37 PM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote: >> On Tue, 4 Sep 2012, Jassi Brar wrote: >>> If we progress the h/w pointer of ALSA ring buffer at URB completion >>> (and not at URB submission) this shouldn't affect the latency. >> >> How would this make any difference? The time between the application >> writing samples to the buffer and the samples actually being played by >> the device would not change. >> > If we advance the pointer immediately after submission, the total time > a sample spends in flight is ring-buffer + queue length. > If we advance the pointer upon completion, the total time a sample > spends in flight is ring-buffer. Yes, if you assume that the nominal ring buffer size is the same in both cases. However, the reason that the buffer size must be chosen by the application is that it has to be balanced between low latency and protection against underruns. If you read the data from the buffer when submitting a URB but advance the pointer only on completion, then this part of the buffer becomes effectively unusable for this amount of time, i.e., the application has to ensure that samples are written long before the pointer actually reaches that part of the buffer. Effectively, this reduces the usable buffer size by the URB queue length. So if you want to have the same amount of underrun protection as the current algorithm, you have to increase the buffer size by the queue length. (Which also increases the latency back to what it was with the current algorithm.) In other words, advance-on-completion with buffer B and queue Q behaves exactly the same as advance-on-submission with buffer B-Q, the only difference being that there is an unusable part of the buffer that applications don't get told about. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
