On Mon, 9 Oct 2006, Christopher "Monty" Montgomery wrote:

> > > Okay.  Then there's nothing to stop you from putting 1 or 2 ms worth of
> > > data in each URB and keeping 2 URBs in the queue at all times.  Except
> > > that you run a high risk of loss-of-sync owing to kernel latency.  But
> > > that will always be true in a low-latency application.
> 
> 2ms of read URB + 2ms or write URB is 4ms, which is already eating
> most of our turn-around time just in buffering.
> 
> > Right ... Monty, remember that a millisecond of IRQ latency is very
> > possible, and is enough to cause an underrun if you don't have an
> > urb with a millisecond's worth of data running while the system hits
> > delays (like, another IRQ handler) before processing the previous URB.

It's amusing watching the two of you talk past each other...  especially 
in regard to issues of latency.

Let's consider a simple case.  Suppose we're using a full-speed controller 
instead of EHCI.  It's easier to analyze and more demanding.  Here's a 
best-case scenario:

    A.  During frame 0 a pressure wave strikes the microphone.  The
        hardware digitizes the signal and stores the data internally.

    B.  During frame 1 the data collected in A is sent to the host.

    C.  At the end of frame 1 the host gets a transfer-completed IRQ.

    D.  During frame 2 the HCD invokes the read URB's callback.  The
        audio driver and application massage and re-buffer the data for 
        retransmission.

    E.  Then the HCD invokes the callback for an old write URB.  The
        audio driver resubmits, using the data generated in step D.

    F.  The HCD takes the submitted URB and schedules it for frame 3.

    G.  During frame 3 the data is sent to the speaker device.

    H.  During frame 4 the speaker plays the data out into the air.

Even with no problems and 0 interrupt latency, there's still a 4-ms delay
between the microphone and the speaker.  With EHCI this can be reduced
somewhat; you could ask the controller to generate IRQs every 0.5 ms
instead of every ms and thereby reduce the delay to 2 ms.  This quickly
leads to diminishing returns, however, because of all the overhead
involved in processing IRQs, invoking callbacks, etc.

In addition, there are two important problems not mentioned above:

The first has to do with the order of the callbacks.  Although I wrote
step E after step D, there's no reason they can't occur in the opposite
order.  When that happens the driver will be in trouble because the data
for E's submission won't be available yet.  The driver could submit dummy
data, but that's foolish given that step D will happen in the very near
future.  Or the driver could submit nothing until step D occurs, which
would cause the endpoint queue to dry up and the bandwidth to be
deallocated.  This is precisely why Monty wants to allow allocations to
survive for some period even with no URBs in the queue.

The second difficulty has to do with kernel latency.  Suppose for one
reason or another the system is busy, and consequently step E doesn't
occur until after frame 3 has already begun.  It wouldn't take much of a
delay, and according to Dave a 1-ms IRQ latency is to be expected every
now and then.  The only way to survive without a dropout is to have an
extra URB in the write queue.  That will give an additional millisecond of
breathing space, at the cost of increasing the microphone-to-speaker delay
by 1 ms.

Perhaps not coincindentally, it turns out that the solution to the second 
problem also solves the first problem.  If you're working with low-latency 
EHCI then the overall delay goes up from 2 ms to 3 ms.  Isn't that still 
low enough to be usable?

(It's worth pointing out that this analysis doesn't mention the depth of 
the read queue.  It doesn't matter how many URBs are waiting in that 
queue; all that matters is how much data each URB can receive.)

Alan Stern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to