On 10/6/06, Alan Stern <[EMAIL PROTECTED]> wrote: > Notice that you didn't answer the question I asked. I asked why you > thought the reservation would be lost, and you replied by explaining why > the reservation could not be recovered once it was lost. My original > question still stands.
What else would cause ALSA to throw EPIPE and the kernel to log 'unable to submit datapipe for urb: error -28' two hours into a live recording? The app involved is a realtime app, the sample thread is running lockless at realtime priority 90, and ALSA never reports an xrun. I'll also note that the recordings also frequently have random gaps in them with no xruns or logs from any layer (so in addition to losing the bandwidth reservation, we're also sometimes missing slots, and nothing is noticing). Something, somewhere, causes the reservation to be lost. > Again, notice that you didn't address my comment. I said that kernel > latency cannot cause a reservation to be lost. You replied by saying that > kernel latency can cause a stream to lose sync. That's very different. > You can lose sync without losing bandwidth reservation. Yes, I noticed that. You win this point. > Once again: losing sync is different from losing a reservation. Yes. And I want to root out the causes of both. 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
