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.