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