On Sat, 10 Oct 2015, Pierre-Louis Bossart wrote:
However, I'm working on a quirk for a device which stuffs an extra four (non sample) bytes into each isochronous packet, and that means that the maxsize calculation must take this into account. During this work it became obvious that there was something wrong with the maxsize calculation, as the resulting packet size when wMaxPacketSize was hit did not correspond to the packet size which triggered the if statement to start with.
That sounds wild and borderline compliant. It's almost as if an encoded format should have been used for this pseudo-PCM with metadata. Are those 4 extra bytes accounted for in what the device endpoint reports? If no, then I fail to understand how the fix would help, you may exceed the max packet size. And this could also screw up the implicit feedback case where the rate is determined by looking at packet sizes.
Ok, to clarify, this patch is not a fix for the device in question. What I wrote was that while working with another patch for that device (Zoom R16), I discovered this problem with the max packet size calculation. So the patch in this thread fixes the packet size calculation, but does not address the problem with the Zoom R16. I thought it better to submit the packet size calculation fix as a separate patch as it is totally unrelated to the R16, and also becuase it might warrant some discussion in its own right. (Also it didn't make sense to make a patch to code that seemed to need fixing first).
FWIW, the Zoom R16 advertises a max packet size of 108 bytes for the capture direction. This is consistent with the 8 byte frame size that the device also advertises, taking into consideration the extra 4 byte descriptor (108 = 8 * 13 + 4).
The Zoom is not class compliant, it advertises itself as being vendor specific, so they could really use any format they want. It just so happens that it is standard PCM with the extra descriptor quirk.
/Ricard