Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1757705AbcLAI77 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Dec 2016 03:59:59 -0500
Received: from mx2.suse.de ([195.135.220.15]:38298 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1757632AbcLAI6j (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Dec 2016 03:58:39 -0500
Date: Thu, 01 Dec 2016 09:58:34 +0100
Message-ID: <s5hy40010w5.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Jiada Wang <jiada_wang@mentor.com>, apape@de.adit-jv.com,
        linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
        Mark_Craske@mentor.com
Subject: Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize
In-Reply-To: <1cb0aa49-62d5-b2ac-a473-bbce3f491d59@ladisch.de>
References: <20161130075923.15205-1-jiada_wang@mentor.com>
        <20161130075923.15205-2-jiada_wang@mentor.com>
        <1cb0aa49-62d5-b2ac-a473-bbce3f491d59@ladisch.de>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.5
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1199
Lines: 34

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