Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
Jiada Wang wrote: > On 11/30/2016 11:41 PM, 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? > > It was a LG nexus So it was the Android audio accessory mode. >>> have a much higher jitter in used packetsizes than 25% >> >> How high? > > the nominal packet size was somewhere around 176bytes > +25% would result in max expected packets to be ~220bytes > We observed some packets exceeding this size (256byte) 256 bytes per USB frame would correspond to 64 kHz, instead of the nominal 44.1 kHz. The audio accessory sample format is fixed, and that mode is no longer developed, so increasing the limit to +50% would be sufficient to work around this problem. I don't know if this is a bug in Google's generic AOA code, or if LG did some changes; I have not heard any other report so far ... Regards, Clemens
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
Jiada Wang wrote: > On 11/30/2016 11:41 PM, 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? > > It was a LG nexus So it was the Android audio accessory mode. >>> have a much higher jitter in used packetsizes than 25% >> >> How high? > > the nominal packet size was somewhere around 176bytes > +25% would result in max expected packets to be ~220bytes > We observed some packets exceeding this size (256byte) 256 bytes per USB frame would correspond to 64 kHz, instead of the nominal 44.1 kHz. The audio accessory sample format is fixed, and that mode is no longer developed, so increasing the limit to +50% would be sufficient to work around this problem. I don't know if this is a bug in Google's generic AOA code, or if LG did some changes; I have not heard any other report so far ... Regards, Clemens
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
Takashi Iwai wrote: > Clemens Ladisch wrote: >> Takashi Iwai wrote: >>> [...] >>> 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. The USB audio specification _requires_ that there is as little jitter as possible. It's no surprise that some device violates the specification. But we don't know what the actual error is; whether we could adjust the packet size for this particular device only, or increase the limit for all devices, or use a completely different workaround. > If maxpacksize fits without +100% as this patch suggests, can we rely > on it instead? The packet size affect the following computations, like the number of packets per URB. I don't know how bad the effects would be. Regards, Clemens
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
Takashi Iwai wrote: > Clemens Ladisch wrote: >> Takashi Iwai wrote: >>> [...] >>> 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. The USB audio specification _requires_ that there is as little jitter as possible. It's no surprise that some device violates the specification. But we don't know what the actual error is; whether we could adjust the packet size for this particular device only, or increase the limit for all devices, or use a completely different workaround. > If maxpacksize fits without +100% as this patch suggests, can we rely > on it instead? The packet size affect the following computations, like the number of packets per URB. I don't know how bad the effects would be. Regards, Clemens
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
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 >
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
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 >
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
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
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
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
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
On Thu, 01 Dec 2016 08:41:17 +0100, 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? thanks, Takashi
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
On Thu, 01 Dec 2016 08:41:17 +0100, 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? thanks, Takashi
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
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? Regards, Clemens
Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
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? Regards, Clemens
