On Thu, 23 Sep 2004, Braman, Paul wrote: > Here's what happens when I start the request...(two URBs, each > requesting 100 frames, reap-read-submit loop): > > 1) Both URBs are submitted. > 2) Loop to reap is started. > 3) URBs with actual_length=0/error_count=0 are returned constantly. (I > assume that it waits for 100 frames of "nothing" and then unblocks the > REAP ioctl to return. The timing looks about right for that.) > 4) I unplug the S/PDIF input to the device and plug it back in. > 6) Several more URBs are returned with actual_length=0/error_count=0. > 7) Streaming starts, with each URB missing 4/5 frames about evenly > spaced throughout. (The initial URB at the start of streaming is > partially full...as you might expect.) Note that it's not the same > frames in each URB that are missing data. If you concatenated all the > frames together the missing frames would be evenly (almost) spaces > throughout.
Hmmm... The uhci-hcd driver has had a few changes recently, but I don't think any of them would affect the behavior you're seeing. Which version of the kernel are you using? The later the better, as far as I'm concerned. It you're not using it already, try 2.6.9-rc2. The driver won't return an URB to the completion routine with status 0 unless it got _some_ response from the device or unless the UHCI hardware is malfunctioning. Your device must really be transmitting empty frames. Here's a test you can do. Turn on the USB debugging option in the kernel configuration and rebuild the driver. When you load the driver, type "modprobe uhci_hcd debug=3". Then while you're running and getting all those empty responses, make a copy of the file in /proc/driver/uhci that corresponds to the controller you're using. Make another copy after replugging the S/PDIF input, so we can see what the data structures look like when there actually is data coming across. Post both copies on the mailing list; they will have lots of information. > When I was running 2.4, the only change to this was that data would > start streaming as soon as the URBs were submitted. In 2.6 I have to > "reinitialize" the streaming by unplugging the S/PDIF input and plugging > it back in to kick-off the data. Since the S/PDIF input can't affect the computer at all, this must be the result of something funny happening within the device. Perhaps your Linux program doesn't initialize it to quite the same state under 2.6 and 2.4, or to the same state as the Windows program. > I could almost get over the reinit stuff if it didn't *still* drop > frames. Short of a hardware problem on the computer, it sounds like the device is dropping them. The data from the test above may tell us more. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
