Alan Stern wrote: > On Fri, 18 Aug 2006, Clemens Ladisch wrote: > > It usually does put more than one packet into each URB, except when > > an application requests interrupts at a higher rate, or when the > > nrpacks module parameter is set to a lower value. > > > > The output from speaker-test indicates that it sets the period size > > to 64 KB (i.e., interrupts every 341 frames), so I guess that > > nrpacks is set to 1. > > Yes, it was. I see the default value is 4 and the max is 10. Could > those values be increased?
Yes, easily. The driver itself doesn't have any inherent upper limit. However, increasing the number of scheduled packets will increase the audio latency. I wouldn't want to have the default be more than 100 ms or so. I'll increase the defaults. > In the latest test in that bug report (attached to comment #20) I > found what appears to be a bug in snd-usb-audio. Here's an extract > from the usbmon log: > > d687f520 993504083 S Zo:002:06 -115 192 = df3fdf3f 893f893f fd3efd3e > d687f5a0 993505076 C Zo:002:06 0 192 > > d687f5a0 993505126 S Zo:002:06 -115 192 = 21c321c3 18c218c2 43c143c1 > d687f620 993506078 C Zo:002:06 -104 192 > > d687f6a0 993506084 C Zo:002:06 -104 0 > d687f120 993506088 C Zo:002:06 -104 0 > d687f1a0 993506093 C Zo:002:06 -104 0 > d687f220 993506097 C Zo:002:06 -104 0 > d687f2a0 993506101 C Zo:002:06 -104 0 > d687f520 993506105 C Zo:002:06 -104 0 > d687f5a0 993513075 C Zo:002:06 0 192 > > d687f120 993514134 S Zo:002:06 -115 192 = 00000000 00000000 00000000 > > As far as I can tell, something caused the driver to cancel its > ongoing activity and restart. Maybe the test program closed the > device file and re-opened it. I'd guess the stream was stopped due to an underrun, i.e., the application didn't fill the buffer fast enough. This shouldn't happen with speaker-test except when something else eats too much CPU. > Anyway, the driver always has eight URBs queued. The URB at d687f5a0 > was the last one submitted before everything was cancelled. The > driver unlinked 7 of the 8 URBs, but the last one was left to > complete normally, 8 ms after it was submitted. That looks like an > off-by-one error in the cancellation code. The only place where URBs are cancelled is in deactivate_urbs(), and the for loop is obviously correct. The only place where bits in active_mask are cleared is in snd_complete_urb() when we know that the URB isn't to be submitted again for whatever reason. I'll do some test over the weekend ... Regards, Clemens ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
