Re: [linux-usb-devel] Claim Interface before snd_usb_audio does

[Jared Holzman]

Somewhere underneath all that sarcasm, I believe that you're saying that the device is violating the size of the isochronous packets. From my point of view this means that the packets are too small as I am interested in getting the device to work, not in fixing its, possibly broken, USB interface. However without a complete understanding of the USB stack, I cannot determine if a) The host informs the device of the sizes and offsets of the packets to use, according to the submitted URB, and then the device is supposed to follow them and if it doesn't you get the -EOVERFLOW? Or b) The URB merely informs the host what size packets to expect and the device sends what it has been configured to send and if they dont match then the -EOVERFLOW occurs? Jared Alan Stern wrote: Please send your messages to the mailing list as well as to me. On Wed, 2 Aug 2006, Jared Holzman wrote: Another quick question, what does the status -EOVERFLOW mean for individual isochronous packets? All the normal USB error codes are explained in Documentation/usb/error-codes.txt. -EOVERFLOW status means the received data packet was larger than expected. Alan Stern Could you be a bit more specific. Does that mean: 1) The individual isochronous packets were too small? No, it means they were too big. That's what "larger than expected" means. Something that is too small is not "larger than expected". 2) There weren't enough isochronous packets No, it doesn't mean there weren't enough of them. It means some of them (the ones that got the -EOVERFLOW status) were larger than expected. In other words, the actual packet size was larger than the value in urb->iso_frame_desc[n].length, where n is the index corresponding to the packet that got the -EOVERFLOW status. 3) The transfer buffer was too small No, if the transfer buffer were too small then usb_submit_urb() would have returned an error immediately. However you could argue that the value in urb->iso_frame_desc[n].length was too small. That's a matter of your point of view: Either the value of the length field was too small or the packet size was too big (or possibly both). All you have told us is that the requirement (the length field) >= (the packet size) was violated. Without more information I can't say whether the fault lies on the left side or the right side of the inequality. 4) Something else... I think by now we have belabored the point sufficiently. Alan Stern

-------------------------------------------------------------------------
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