> > 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.

Hmm... I wonder if MacOSX is doing something special with low latency
EHCI _scheduling_ specifically; I know it is special casing the low
latency cases extensively.  We may have to as well if we want this to
work.  I'll go read the Darwin code.

Also on the table today: run the low latency case with logging and
test the theory of 'what's happening' with more precision.  Although
it really does sound like there are at least five different 'it wasn't
designed for this' sticking points.

I suppose we could just give up and say 'Linux can't do this and won't
for some time'...  AFAIK, the only paying customers that are actually
actively pissed off about this are Nokia.  I'm not a paying customer,
I just have to feed the puppy :-P

Monty

-------------------------------------------------------------------------
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