On Tue, 23 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
On Fri, 19 Apr 2013, Joe Rayhawk wrote:
On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote:
On Fri, 19 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
next = uhci->frame_number + 2;That 2 is the minimum latency, in frames (one frame per ms).
One frame worked fine with the old driver. What is the reason for this regression?
Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem.
Hey, that worked great! Audio's coming through continuously, now.
This change could be added to the driver, but I would prefer not to.
Why do you think it is necessary to have a minimum latency of 2 ms?
To avoid underruns. Perhaps this is unnecessary caution on my part.
Again, the old algorithm worked fine. While such short queues are not used by default, they are necessary to get low latencies for real-time audio applications. Keeping this change would keep this regression for quite a few people.
Okay, I will change the 2 to 1 since you think that is best.
In any case, it would be best
What criteria are you using to evaluate the benefit of this? Do you want to reduce the chance of queue underruns? Interrupts? Power usage?
Chance of underruns.
if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times.
Why is having a queue of two URB with one packet each suddenly not allowed?
It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns.
Alan Stern
-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html