[alsa-devel] BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'

[Alan Stern]

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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html