On Fri, 6 Oct 2006, Christopher "Monty" Montgomery wrote: > Sorry, I just realized we've been talking about the effects of two > different xrun cases.
No, we've been talking about xrun vs. reservation loss. > Xrun type 1: 'an xrun happened in the schedule'; we missed scheduling > a slot, but not because buffers starved. We didn't service the > schedule fast enough. This is what would happen with excessive kernel latency, right? > Reporting this xrun does not in fact cause the > ehci driver to release the stream, When usbaudio sees the error, it > shuts down the stream, which is a different issue. > > Xrun type 2: buffer starvation because the higher level driver was not > fed fast enough. This would cause the bandwidth allocation to be > dropped in your ideal scheduler, but not in mine. No. You still don't understand what I've been saying. ehci-hcd (or any HCD for that matter) is completely ignorant of what the higher-level driver gets fed. All it knows about is what the higher-level driver tells it. As long as the higher-level driver continues submitting URBs the allocation won't be lost. There's no reason in the world the driver can't do so even when it isn't fed fast enough. The higher-level driver's decisions about submitting URBs don't need to bear any relation to how rapidly an application feeds it data. > So I brainoed above and was incorrect. Kernel latency can cause an > *xrun*, not the bandwidth to be released. If the bandwidth is > released, it's because a higher driver did it. Now you've got it. > It is still the case that not being able to distinguish between normal > shutdown and xrun in case 2 is scary, again because USB bandwidth > allocation is fragile. The 'xrun and shutdown are the same' is > suboptimal only because of this fragility. But it doesn't make the > fragility go away. Who says you can't distinguish them? The higher-level driver certainly can distinguish them. It knows whether or not it has been resubmitting URBs in the completion handler. Whether (or how) it chooses to report this information to an application is a separate matter, something that ehci-hcd doesn't need to be concerned about. 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
