On Wed, 5 Sep 2012, Clemens Ladisch wrote: > Alan Stern wrote: > > On Tue, 4 Sep 2012, Jassi Brar wrote: > >>> Second, people involved in real-time programming (such as audio or > >>> video) generally want to keep latency to a minimum. > >> > >> If we progress the h/w pointer of ALSA ring buffer at URB completion > >> (and not at URB submission), > > > > I don't understand this comment. As far as I can tell, the relevant > > pointer already is being advanced during URB completion. > > It's advanced directly after submission. The queued data is double- > buffered because the USB API lacks the ability to scatter/gather from > a coherent buffer. Actually it does have this ability, but only to a limited extent. I don't remember what the restrictions are (and they probably aren't documented anywhere). Certainly the data for each packet has to be contiguous. There may be an assumption that the packets are stored in sequential increasing order in memory, and there may be a limitation on the distance between the starts of neighboring packets. I'm also not sure to what extent these restrictions could be relaxed. > >> 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. This depends on how rapidly the program writes the samples. If they are written at about the same rate as they are played out then using a longer queue _will_ increase the latency, because the samples won't start playing until the queue is full. (I don't see how this is related to whether the buffer pointer is advanced at URB submission vs. URB completion, but never mind...) Alan Stern -- 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
