On 10/9/06, Alan Stern <[EMAIL PROTECTED]> wrote: > On Mon, 9 Oct 2006, Christopher "Monty" Montgomery wrote: > > > On 10/9/06, Alan Stern <[EMAIL PROTECTED]> wrote: > > > So you're saying if the current uframe is N when you receive an URB whose > > > first slot belongs in uframe N+1, then you have to reject it, right? > > > > No, that we try to fill the slot and if the clock is at/past the slot > > when we're done filling, look to see if the slot was processed. If it > > wasn't, unlink it and return loss of sync. > > What happens if, when you're done filling, the clock is exactly at the > slot? Unless you wait for the clock to move past the slot, you can't know > whether or not the slot will end up being processed. But you can't wait > during a submit, so what do you do?
That... is a good point. I submit the following: You accept it, the clock is not past. Assume for the time being it scheduled in time. If it didn't, that's reported at the next submission (still semantically correct: the XRUN is still happening then). Reporting -EXDEV in the completion handler gets you nothing because that URB isn't going to complete; it missed its slot. Hm, interestingly though, neither case works if that was the last URB to be submitted before stream shutdown. You'll get neither a next submission nor a completion. We'd have to hack the missed slot to complete artificially, or have scan-periodic look for failed slots (which strikes me as possibly the cleanest approach). > There is more than one way to encapsulate this, and I don't particularly > like the way you're suggesting. The reason I don't like it is because it > won't always work -- as you can see from the example given just above. Indeed, if it doesn't always work sensibly, I won't like it either. I'm not quite convinced it's worth dismissing yet. OSes with USB implementations that work much better than ours do it; that's not a conclusive argument, but we should be giving the idea a little more scrutiny for that reason. There's not real precedent in either direction as it appears the higher level drivers expect neither channel as yet. Either way will involve work. 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
