From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7592C64E7D for ; Fri, 27 Nov 2020 09:22:05 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1B74A221FF for ; Fri, 27 Nov 2020 09:22:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="FrAnf8Kw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B74A221FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id E73941828; Fri, 27 Nov 2020 10:21:11 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E73941828 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1606468922; bh=MYKZgNnZxY/1xmIUX1eaBCMC34vKzmS3Uyo9N7H/QtA=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=FrAnf8Kw81Uj+4kILaMp6fJj3n1LAVy5/IiO9yOItDSQBsof2AFDnACao5o5cKQMj NU62LwZ1q2q8aHlqddjkan3I6tNFdnkcn+0PoDYFnI8HK4yb8M/ABPVq4kJjq6qVEB whlf8UESOjJfS57Q+1HOZM1r3lpx/lkPlQB400o4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 70FBCF8015F; Fri, 27 Nov 2020 10:21:11 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 23CCAF8019D; Fri, 27 Nov 2020 10:21:10 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id DE7DCF8015A for ; Fri, 27 Nov 2020 10:21:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz DE7DCF8015A X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 59444AC2F; Fri, 27 Nov 2020 09:21:01 +0000 (UTC) Date: Fri, 27 Nov 2020 10:20:59 +0100 Message-ID: From: Takashi Iwai To: Ben Bell Subject: Re: Behringer WING usb audio - cyclic xruns dependent on periods/buffers In-Reply-To: <20201126180612.E3E0CF80166@alsa1.perex.cz> References: <20201126180612.E3E0CF80166@alsa1.perex.cz> 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/25.3 (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 Cc: alsa-devel@alsa-project.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Thu, 26 Nov 2020 19:06:04 +0100, Ben Bell wrote: > > I've got a Behringer WING digital mixer which is equipped with a USB > interface supporting 48 in, 48 out at 44.1 or 48kHz. It's plugged into a > USB3 interface and for the most part it seems to work well as a class-compliant > audio interface, but I'm struggling to eliminate xruns and it's starting to > feel either driver or hardware quirk related issue. > > I've done all the usual things -- I'm running a PREEMPT_RT kernel, set up > the realtime priorities of Jack and the relevant USB IRQ to no avail. I'm > doing most of the debugging remotely over ssh with X shutdown and most > other processes on the system stopped. There's nothing plugged into the > computer beyond network, keyboard, mouse and the audio interface. > > I'm currently testing on kernel 5.10.0-rc5 with preempt-rt patches, but I've > previously seen the same things on 5.4-rt (Debian backports) and 5.8 > (self-compiled). > > The xruns are characterised by bursts of "retire_capture_urb" warnings in > the kernel logs (and in particular the frame status for everything in those > URBs is EXDEV, meaning I think that the frames haven't been consumed by the > time it's retired). I've patched sound/driver/pcm.c to provide me with a bit > more debugging information and it looks like usually it's almost always > between 7-10 consecutive calls to retire_capture_urb that are affected. > > The bursts of retire_capture_urb warnings seem roughly cyclic, with a > cycle time that is dependent on the combination of the frames/period setting > and the number of periods per buffer, though it doesn't appear to be a > strictly linear thing: 512/2 (~170s cycle); 256/2 (~94s); 128/3 (~65s); > 64/13 (~270s). I can't immediately see any definitive smoking gun in the urb > or interrupt counts, but there is some grouping in the timings between > the xruns. Taking 64 frames, 5 periods, it's usually 50s, but sometimes 60s: > > 21:47:57 50s since xrun 4 > 21:48:47 50s since xrun 5 > 21:49:46 59s since xrun 6 > 21:50:46 60s since xrun 7 > 21:51:36 50s since xrun 8 > 21:52:36 60s since xrun 9 > 21:53:36 60s since xrun 10 > 21:54:37 61s since xrun 11 > 21:55:27 50s since xrun 12 > 21:56:27 60s since xrun 13 > 21:57:27 60s since xrun 14 > 21:58:17 50s since xrun 15 > 21:59:16 59s since xrun 16 > 22:00:06 50s since xrun 17 > 22:00:56 50s since xrun 18 > ... > > If I count the URB numbers (sorry, I'm shaky on the terminology, but I'm > counting each URB which is retired) I often (but not always) see the same > number of URBs passing between xrun bursts. Currently at 64 frames/5 > periods, it's often exactly 50042 or 49923 urbs between bursts. > > The delay between starting Jack and encountering the first burst is not > predictable -- it's not just a whole cycle -- but stopping jack for e.g 30s > then starting again delays the next burst by the same amount. So it does seem > related to something in the audio streaming rather than anything else going on > on the system interfering. It's as if something is slowly slipping out of sync > between the Wing and the kernel until they need to resync, but I don't really > know enough about USB to have any deeper insight. > > All the tests above happen to be at 44.1kHz with the Wing set to 48 in, > 48 out, but changing to 48kHz or 2/2 IO doesn't seem to cure anything. > > One more data point which may not be relevant: if I switch off or unplug > the Wing while Jack is running, the system gradually locks up over a period of > a few seconds. I can get something out of the console briefly afterwards but > within about ten seconds it's completely unresponsive. I imagine that pulling > out a USB device from a realtime thread isn't a kind thing to do, but I don't > recall this happening with other interfaces. > > Any help or insights into where I should be looking (I'm a newbie in kernel > space) appreciated. If someone wants remote access to the box to investigate > in realtime we could probably figure something out. In general you should avoid 44.1kHz if you want a small period size for a realtime process on USB-audio. With 44.1kHz, the packet size can't be fixed in integer, and the ISO transfer requires variable packet sizes. OTOH, ALSA API requires the fixed period size, hence it'll lead to inconsistencies occasionally. Takashi