On Thu, 01 Dec 2016 12:16:47 +0100, Clemens Ladisch wrote: > > 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. Well, the question is what is the "sane" range. +25% doesn't fit for some devices. If maxpacksize fits without +100% as this patch suggests, can we rely on it instead? Takashi > > > I'm wondering if that unknown device just declares a wrong interval value. > > > Regards, > Clemens > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
