Takashi Iwai wrote:
Clemens Ladisch wrote:
Jiada Wang wrote:
since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected packetsize is always limited to nominal + 25%. It was discovered, that some devices
Which devices?
have a much higher jitter in used packetsizes than 25%
How high? (Please note that the USB specification restricts the jitter to at most one frame in consecutive packets.)
which would result in BABBLE condition and dropping of packets. A better solution is so assume the jitter to be the nominal packetsize
This solution is better for this one particular device, but how does it affect normal devices, or the Scarlett 2i4 on EHCI affected?
Actually, which value does this affected device in ep->maxpacksize? In the commit mentioned above, we changed the logic to take +25% frequency as the basis, and it my *reduce* if ep->maxpacksize is lower than that.
OTOH, if ep->maxpacksize is sane, we can rely on it rather than the implicit +25% frequency. That said, maybe we can check ep->maxpacksize whether it fits within the expected range, then adapt it, or take +25% freq as fallback?
You are describing how the current code behaves. The +25% limit _is_ what the code takes as the expected range.
I'm wondering if that unknown device just declares a wrong interval value.
Regards, Clemens