On 10/8/06, Christopher Monty Montgomery <[EMAIL PROTECTED]> wrote: > Right now, that attempt would be outright rejected. ehci-sched will > not (and never would) schedule into the currently active frame. In > fact, it would not schedule into any frame within 'SCHEDULE_SLOP' of > the active frame. I did not change that behavior.
Actually, I erred slightly above; the original ehci would not perform initial scheduling less than SCHEDULE_SLOP frames out, but if a schedule had already been planned, it would not do any checks before filling a slot. So it would try to schedule current frame, I believe. So, I did change the behavior and that's an error in my code; it should not be enforcing that were' *always* at least SCHEDULE_SLOP deep. Chalk up one more bug in the patchset. More importantly, this might explain why low latency never worked. There were always constant xruns that ALSA didn't detect. Please sanity check this thinking, but it explains what I observed (every submission had to reschedule)... When sample and playback are lockstep (read 64 samples, process, write them for playback, read next 64 samples, process, write them for playback), we will only ever be one URB deep. There will never be another URB waiting. So, every read and every write will complete the 'last' URB and shut the stream down. Not only does that force rescheduling, but it also means that due to the SLOP, it could not possibly be scheduled for the next slot. There would always be a gap. Is this a plausible explanation? I can put a little time in tomorrow demonstrating one way or the other with certainty if so... Monty > > > No way to know until the > > > microframe is finished. The only way ehci-hcd can make an accurate report > > > in this case is to _always_ report that the slot was missed -- not even > > > _try_ to add it into the hardware schedule -- even if it might have been > > > possible for the slot to be filled. > > ...or check the uframe clock when the schedule is complete and if it > still precedes the slot... > > [or are you worried about caching and propogation of changes?] > > > Actually that's a good description of the case where that -EXDEV fault > > might reasonably be reported at completion. > > Yes, agreed, if we really can't reliably figure it out ahead of time. > > > And I was wrong about EHCI (at least) reporting that ... since that's > > the initial value for each (micro)frame's transfer status, EHCI will > > report that when collecting an ITD that sitll has ITD_ACTIVE set. > > But, hmm bug!, not (yet) SITDs with SITD_ACTIVE. (Monty, that would > > seem to be something you might fix in one of your patchsets ... it's > > trivial, but I don't want to create needless problems for your patches!) > > Yes, good catch. I'll make that change. > > Monty > > > > > - Dave > > > > > ------------------------------------------------------------------------- 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
