On 10/6/06, Christopher Monty Montgomery <[EMAIL PROTECTED]> wrote: > On 10/6/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > You still don't seem to understand. Kernel latency by itself _cannot_ > > cause a bandwidth reservation to be lost. > > I call bullshit. A single well-placed printk inside the spinlock is > enough latency to cause all the iso streams to lose sync. That > spinlock can also be held be preemptible code. Etc. Sorry, I just realized we've been talking about the effects of two different xrun cases. 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. 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. 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. 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. 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
