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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3DB4AC4332F for ; Tue, 22 Nov 2022 07:26:28 +0000 (UTC) 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 D107A165D; Tue, 22 Nov 2022 08:25:35 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D107A165D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1669101985; bh=xIMec4A63W0wMjfwbORTjnXG3VOKVKj8a2qOs093c8Y=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=hedi69LpNsHPQZqw3+Tu1TWs/BmyWNyMGVIoKc3Ywi3WZK67u/gWfeBypL2zqSGM3 7bjyXM6TsmWgjf7eE4TOML0oREqR/7AxKSnisZWcdBiTpCWB7/rueixNvAWST3kpE6 +GopbMQJCUlhpLiCzHK7lP9GYHH+my93qWbsDCIs= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 7B8F8F80149; Tue, 22 Nov 2022 08:25:35 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 87DFFF80272; Tue, 22 Nov 2022 08:25:33 +0100 (CET) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 88755F80149 for ; Tue, 22 Nov 2022 08:25:30 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 88755F80149 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="r9tSLbjD"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="IczhkRtx" Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C1A3E22012; Tue, 22 Nov 2022 07:25:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669101929; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MXqm2Xm0gAmGAFR/ZYj/oTSRfEYvmWngcDHpTR8lf3A=; b=r9tSLbjDb6EJ7ozWqkYeSgmzeOV5dIvBIadrmxLZIOMRDHLQSZifxlLS0gab7/OaACN+ei a+csOd+8RE40QyqM26mT6jBjO7zUkNddFIiRl8rBJjnl8robhETMuN6TRYp7SzUo1OE9U3 wvABtYIWHRHiaIz7RrQiPjVZDoEkDmg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669101929; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MXqm2Xm0gAmGAFR/ZYj/oTSRfEYvmWngcDHpTR8lf3A=; b=IczhkRtxiVKssyk8jnSz1fx8hEhK6ID6z8OPd+0X0Y7d2+5anItDQMkt4RRhJWnuUXeGap rx9TvpJFjUfUFICg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A928813AA1; Tue, 22 Nov 2022 07:25:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id pZ2ZKGl5fGMIeAAAMHmgww (envelope-from ); Tue, 22 Nov 2022 07:25:29 +0000 Date: Tue, 22 Nov 2022 08:25:29 +0100 Message-ID: <87y1s3v4ba.wl-tiwai@suse.de> From: Takashi Iwai To: Carl Hetherington Subject: Re: Query about xrun on usb/pcm In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") 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 Mon, 21 Nov 2022 22:14:39 +0100, Carl Hetherington wrote: > > Hi all, > > I wonder if anybody has any clues/suggestions about problem I'm seeing > with an XMOS-based USB sound card. > > As far as I can see, the card has endpoint 0x82 set up for capture data, > 0x2 for playback data, and 0x82 is also used as the sync endpoint for > playback. I'm assuming that's a fairly common arrangement? Yes, that's an oft-seen implicit feedback mode. You seem hitting a corner case of dealing with that mode... > I am testing it using simultaneous playback and capture, and simulating > a high-CPU-load case by sleeping for long enough to cause a lot of > xruns. After some random time, I see a failure case that I'm struggling > to explain. It goes like this: > > There's an XRUN on the playback PCM, so __snd_pcm_xrun happens, then > stop_endpoints() happens, and: > it decides not to stop 0x82 because its running is > 1 > it stops 0x2, so its state goes to EP_STATE_STOPPING > > Then the ALSA userspace code calls prepare on the playback PCM to get it > going again. > > This ends up in wait_clear_urbs(), which does nothing with 0x82 as it is > still running. So far, so good. > At this point, the prepare thread is interrupted by an XRUN on > the capture PCM. With this PCM, there is no sync endpoint, and 0x82 is the data > endpoint. > In the xrun handler: > stop_urbs() sets 0x82 to EP_STATE_STOPPING. > ... and the xrun handler finishes. > > Then we end up back in the prepare for the playback PCM. > wait_clear_urbs() then sets 0x2 to STOPPED, and the prepare is finished. > > Now, snd_usb_endpoint_start() is called on 0x2 and that is fine. Next, > snd_usb_endpoint_start() is called on 0x82 and that fails because its > state is still STOPPING. > > At this point things seem broken. > > Does anyone have a hint about where in this sequence things are going > wrong, and maybe even why? The problem is that it's treating XRUNs on the both streams individually. It's correct to recover only the PCM stream when an XRUN is reported to the PCM stream. However, for an XRUN on the capture stream that serves as a sync source, it should stop and recover not only the capture PCM stream but also the playback stream as a sync sink as well. Below is a possible test fix (totally untested!). This may give XRUNs twice eventually, which is a bit confusing, but it aligns with the actual hardware behavior, at least. thanks, Takashi -- 8< -- --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -403,10 +403,15 @@ static int prepare_inbound_urb(struct snd_usb_endpoint *ep, static void notify_xrun(struct snd_usb_endpoint *ep) { struct snd_usb_substream *data_subs; + struct snd_usb_endpoint *ep_sink; data_subs = READ_ONCE(ep->data_subs); - if (data_subs && data_subs->pcm_substream) + if (data_subs && data_subs->pcm_substream) { snd_pcm_stop_xrun(data_subs->pcm_substream); + ep_sink = READ_ONCE(ep->sync_sink); + if (ep_sink) + notify_xrun(ep_sink); + } } static struct snd_usb_packet_info *