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

Tue, 08 Aug 2006 05:57:05 -0700

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to