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 29304C433FE for ; Tue, 22 Nov 2022 14:20:12 +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 4FF3B1634; Tue, 22 Nov 2022 15:19:20 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 4FF3B1634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1669126810; bh=gGLtxqxgdmp2fiu5/S2HGh27UKNCeagZB0EfiOzJ674=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=cNdVlPvB7QP0u7j3fgELKnNH4CiCf2tO53TZtuLwgNi0v5SXf37PKNzQyQP485g8q 9AlByGGcxVvyFx2kbw9WS5CefwnlXhEqX0jgpb/gr/9LjvgQyLZtE9qBnVFifqg2hR mpVWjSl2TC6IXii47t7CR1ZmCIEMmEAvfde2Ci4A= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id E147CF8026A; Tue, 22 Nov 2022 15:19:19 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 0A122F80272; Tue, 22 Nov 2022 15:19:18 +0100 (CET) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (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 64ACDF80154 for ; Tue, 22 Nov 2022 15:19:14 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 64ACDF80154 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="wW4ikBwf"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="mnY1uBxT" 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-out2.suse.de (Postfix) with ESMTPS id 614B71F85D; Tue, 22 Nov 2022 14:19:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669126754; 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=sozG0BEMAlaClN3fBIU6s27JtHUQ8B3q9v0peIhMtls=; b=wW4ikBwfiDZ0KD81wb+BjfGIlT3GfwDr6KccCB7PrijUdv4NUKXH3gemSCoSBg056n8aBb +82VXASMUc1bKnN7AlJ3GWPdkRoeuoF16VIea7FlAYJaGa/FBsjNxQ1YCUwisMvyLkeEJN 9BgYSZbMtzM4GiFz4sV+uh4onKdEpPo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669126754; 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=sozG0BEMAlaClN3fBIU6s27JtHUQ8B3q9v0peIhMtls=; b=mnY1uBxT3h6In6TSwqtreWdPLfbIX+jZ1ZnP/OC59xZA4DJljFTtmH/qq6n/AlWN0pCdql l6T5iS2aKoi3xrDA== 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 45C4A13AA1; Tue, 22 Nov 2022 14:19:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 2z9NEGLafGMvbQAAMHmgww (envelope-from ); Tue, 22 Nov 2022 14:19:14 +0000 Date: Tue, 22 Nov 2022 15:19:13 +0100 Message-ID: <87edtv6pi6.wl-tiwai@suse.de> From: Takashi Iwai To: Carl Hetherington Subject: Re: Query about xrun on usb/pcm In-Reply-To: References: <87y1s3v4ba.wl-tiwai@suse.de> 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 Tue, 22 Nov 2022 12:16:47 +0100, Carl Hetherington wrote: > > Hi Takashi, > > Thank you for getting back to me! > > On Tue, 22 Nov 2022, Takashi Iwai wrote: > > [snip] > > > > 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. > > [snip fix] > > Makes sense, thank you! Sadly, the fix doesn't seem to work because (I > think) the xruns I'm seeing come via a different path (not though > notify_xrun()). Mine arrive via this trace: > > __snd_pcm_xrun > snd_pcm_update_state > snd_pcm_update_hw_ptr > usb_hcd_giveback_urb > snd_pcm_period_elapsed_under_stream_lock > snd_pcm_period_elapsed > retire_capture_urb > snd_complete_urb > > I'll see if can apply a similar fix to this case, though to my naive > eyes it looks a little trickier as the xrun is found in the snd_pcm > code rather than the USB code. Any suggestions most welcome! OK, then it's a bit different problem, and not so trivial to fix in the kernel side alone, I'm afraid. Basically it's a race between start and stop of two streams. The key point is that, for stopping a (USB) stream, a sync-stop operation is needed, and this can't be performed at the PCM trigger itself (which is an atomic operation). So, the kernel trigger may at most return an error there. I assume that it's from snd_usb_endpoint_start() and it returning -EPIPE error. If so, we may change the PCM core code to set the PCM state again XRUN in such an error case, so that application may repeat the standard recovery process. Something like below. Takashi -- 8< -- --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -1424,9 +1424,14 @@ static int snd_pcm_pre_start(struct snd_pcm_substream *substream, static int snd_pcm_do_start(struct snd_pcm_substream *substream, snd_pcm_state_t state) { + int err; + if (substream->runtime->trigger_master != substream) return 0; - return substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_START); + err = substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_START); + if (err == -EPIPE) + __snd_pcm_set_state(runtime, SNDRV_PCM_STATE_XRUN); + return err; } static void snd_pcm_undo_start(struct snd_pcm_substream *substream,