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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFC20C433F5 for ; Mon, 3 Jan 2022 12:36:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229978AbiACMgo (ORCPT ); Mon, 3 Jan 2022 07:36:44 -0500 Received: from smtp-out2.suse.de ([195.135.220.29]:60340 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229596AbiACMgn (ORCPT ); Mon, 3 Jan 2022 07:36:43 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id CEAFB1F38B; Mon, 3 Jan 2022 12:36:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1641213402; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QODq8kjaiAS1r6YCPI2sk/kWDpFhJIfFZIOV4hjmVyg=; b=Uf/0ch574uek5qfZRVAzkw7zP67xmz4mycnr/JvOlKLKBjCR7wOCpVnDPjlXif1Q9006Jh 3kQ/fL7uy8NeI6e2y/puCZwwfG8Xe4UFWp//YPb2O8FsiVghtBySmEk5+TgBp69kEORSWt hcRqWUjNkQxD5Y8bmT9UT17pSkg5qJI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1641213402; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QODq8kjaiAS1r6YCPI2sk/kWDpFhJIfFZIOV4hjmVyg=; b=kN+NQ7UEAdAZkrH1f0B8P+KkKBxsAtpdgMzTLBI6tDuU/IdSuLeSSKHL+2mooIyzG4duZD F/V3psuqgQQ8TPAQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id A8AB6A3B85; Mon, 3 Jan 2022 12:36:42 +0000 (UTC) Date: Mon, 03 Jan 2022 13:36:42 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela Cc: Pavel Hofman , "alsa-devel@alsa-project.org" , Julian Scheel , Jack Pham , "linux-usb@vger.kernel.org" , John Keeping , Ruslan Bilovol , Yunhao Tian , Jerome Brunet Subject: Re: Correct stopping capture and playback substreams? In-Reply-To: <581f6464-37ef-9ab6-e7e2-657ad645aa9e@perex.cz> References: <448e059f-fbac-66ed-204b-f6f9c2c19212@ivitera.com> <9635d70f-dc12-f9ed-29f5-ce34a1d4b112@ivitera.com> <581f6464-37ef-9ab6-e7e2-657ad645aa9e@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=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Mon, 03 Jan 2022 13:28:17 +0100, Jaroslav Kysela wrote: > > On 03. 01. 22 13:15, Takashi Iwai wrote: > > On Mon, 03 Jan 2022 12:32:53 +0100, > > Pavel Hofman wrote: > >> > >> > >> > >> Dne 03. 01. 22 v 10:10 Jaroslav Kysela napsal(a): > >>> On 03. 01. 22 9:22, Pavel Hofman wrote: > >>>> > >>>> Dne 23. 12. 21 v 9:18 Pavel Hofman napsal(a): > >>>>> Hi Takashi, > >>>>> > >>>>> I am working on stopping alsa streams of audio USB gadget when USB host > >>>>> stops capture/playback/USB cable unplugged. > >>>>> > >>>>> For capture I used code from AK4114 SPDIF receiver > >>>>> https://elixir.bootlin.com/linux/latest/source/sound/i2c/other/ak4114.c#L590: > >>>>> > >>>>> > >>>>> > >>>>> static void stop_substream(struct uac_rtd_params *prm) > >>>>> { > >>>>>       unsigned long _flags; > >>>>>       struct snd_pcm_substream *substream; > >>>>> > >>>>>       substream = prm->ss; > >>>>>       if (substream) { > >>>>>           snd_pcm_stream_lock_irqsave(substream, _flags); > >>>>>           if (snd_pcm_running(substream)) > >>>>>               // TODO - correct handling for playback substream? > >>>>>               snd_pcm_stop(substream, SNDRV_PCM_STATE_DRAINING); > >>>>>           snd_pcm_stream_unlock_irqrestore(substream, _flags); > >>>>>       } > >>>>> } > >>>>> > >>>>> For setup I found calling snd_pcm_stop(substream, SNDRV_PCM_STATE_SETUP) > >>>>> (https://elixir.bootlin.com/linux/latest/source/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c#L63) > >>>>> > >>>>>    Or for both capture and playback using SNDRV_PCM_STATE_DISCONNECTED > >>>>> (https://elixir.bootlin.com/linux/latest/source/sound/core/pcm.c#L1103). > >>>>> > >>>>> Or perhaps using snd_pcm_dev_disconnect(dev) or snd_pcm_drop(substream)? > >>>>> > >>>>> Please what is the recommended way? > >>>>> > >>>> > >>>> Please can I ask for expert view on this issue? E.g. in SoX stopping the > >>>> stream with SNDRV_PCM_STATE_SETUP/SNDRV_PCM_STATE_DRAINING does not stop > >>>> the application, while with SNDRV_PCM_STATE_DISCONNECTED SoX exits with > >>>> non-recoverable status. I am considering implementing both methods and > >>>> letting users choose their suitable snd_pcm_stop operation (none > >>>> (default)/SETUP-DRAINING/DISCONNECTED) for the two events (host > >>>> playback/capture stop, cable disconnection) with a configfs param. Would > >>>> this make sense? > >>> > >>> The disconnection state is unrecoverable. It's expected that the > >>> device will be freed and cannot be reused. > >>> > >>> If you expect to keep the PCM device, we should probably introduce a > >>> new function which puts the device to the SNDRV_PCM_STATE_OPEN > >>> state. In this state, all I/O routines will return -EBADFD for the > >>> applications, so they should close or re-initialize the PCM device > >>> completely. > >>> > >>> https://elixir.bootlin.com/linux/latest/source/sound/core/pcm_native.c#L794 > >>> > >> > >> The fact is that after closing the USB host can re-open the device > >> with different samplerate (and perhaps later on with different > >> channels count/sample size). That would hint at the need to > >> re-initialize the gadget side before opening anyway. > >> > >> As of keeping the device - it's likely some use cases would prefer > >> keeping the device, to minimize the operations needed to react to the > >> host-side playback/capture start. > >> > >> A function you describe would make sense for this. IMO from the gadget > >> POW there is no difference between the host stopping playback/capture > >> and cable disconnection, in both cases the data stream is stopped and > >> next stream can have entirely different parameters. Maybe the gadget > >> configfs parameter could only toggle between no action (i.e. current > >> situation) and the new alsa function stopping the stream. > >> > >> Jaroslav, please can you draft such a function? Perhaps both changes > >> could make it to 5.17. > > > > (Sorry for the delayed response, as I've been on vacation and now > > catching up the huge pile of backlogs...) > > > > About the change to keep PCM OPEN state: I'm afraid that the > > disconnection in the host side may happen at any time, and keeping the > > state OPEN would confuse the things if the host is indeed > > unrecoverable. > > I don't think so. The SNDRV_PCM_IOCTL_HW_PARAMS must be issued by the > application (in the PCM_OPEN state) and if the USB bus connection is > no longer active, it may fail. We can distinguish between host -> > device disconnection and device -> host one. It is not really a > similar thing. Well, I don't know whether we have a proper protocol to downgrade the state from RUNNING to OPEN. Currently the valid state transition seems to be RUNNING -> SETUP, XRUN, or DISCONNECTED. So, if any, this might be a two-step procedure. thanks, Takashi 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 C4AE7C433F5 for ; Mon, 3 Jan 2022 12:37:44 +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 50734178B; Mon, 3 Jan 2022 13:36:52 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 50734178B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1641213462; bh=pNt8nM7fmJMoAPb/jI7/z9uPlgoAwgHXBGKpvEcz4Jg=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=eQ3PBNZsJpeU+1s5JLp7405UpxRRD8MVDGsD1WyVFa0Ql7bKzekiH7/5A11vDXxAl N5sthypsJKoXsMFEFqK8kG9Lnz18pfxpAYiTg31UW39C+3Ix+D3XCHF02Qnx+4Ao4X Ds2shWdTEOBNXYekDOOJYquaSgqEpmzqyPMgU9a0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id E050BF800FF; Mon, 3 Jan 2022 13:36:51 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 0660EF80107; Mon, 3 Jan 2022 13:36:50 +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 D1A77F8007E for ; Mon, 3 Jan 2022 13:36:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz D1A77F8007E Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="Uf/0ch57"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="kN+NQ7UE" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id CEAFB1F38B; Mon, 3 Jan 2022 12:36:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1641213402; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QODq8kjaiAS1r6YCPI2sk/kWDpFhJIfFZIOV4hjmVyg=; b=Uf/0ch574uek5qfZRVAzkw7zP67xmz4mycnr/JvOlKLKBjCR7wOCpVnDPjlXif1Q9006Jh 3kQ/fL7uy8NeI6e2y/puCZwwfG8Xe4UFWp//YPb2O8FsiVghtBySmEk5+TgBp69kEORSWt hcRqWUjNkQxD5Y8bmT9UT17pSkg5qJI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1641213402; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QODq8kjaiAS1r6YCPI2sk/kWDpFhJIfFZIOV4hjmVyg=; b=kN+NQ7UEAdAZkrH1f0B8P+KkKBxsAtpdgMzTLBI6tDuU/IdSuLeSSKHL+2mooIyzG4duZD F/V3psuqgQQ8TPAQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id A8AB6A3B85; Mon, 3 Jan 2022 12:36:42 +0000 (UTC) Date: Mon, 03 Jan 2022 13:36:42 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela Subject: Re: Correct stopping capture and playback substreams? In-Reply-To: <581f6464-37ef-9ab6-e7e2-657ad645aa9e@perex.cz> References: <448e059f-fbac-66ed-204b-f6f9c2c19212@ivitera.com> <9635d70f-dc12-f9ed-29f5-ce34a1d4b112@ivitera.com> <581f6464-37ef-9ab6-e7e2-657ad645aa9e@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=UTF-8 Content-Transfer-Encoding: 8bit Cc: Julian Scheel , "alsa-devel@alsa-project.org" , Pavel Hofman , "linux-usb@vger.kernel.org" , Jack Pham , John Keeping , Ruslan Bilovol , Yunhao Tian , Jerome Brunet 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, 03 Jan 2022 13:28:17 +0100, Jaroslav Kysela wrote: > > On 03. 01. 22 13:15, Takashi Iwai wrote: > > On Mon, 03 Jan 2022 12:32:53 +0100, > > Pavel Hofman wrote: > >> > >> > >> > >> Dne 03. 01. 22 v 10:10 Jaroslav Kysela napsal(a): > >>> On 03. 01. 22 9:22, Pavel Hofman wrote: > >>>> > >>>> Dne 23. 12. 21 v 9:18 Pavel Hofman napsal(a): > >>>>> Hi Takashi, > >>>>> > >>>>> I am working on stopping alsa streams of audio USB gadget when USB host > >>>>> stops capture/playback/USB cable unplugged. > >>>>> > >>>>> For capture I used code from AK4114 SPDIF receiver > >>>>> https://elixir.bootlin.com/linux/latest/source/sound/i2c/other/ak4114.c#L590: > >>>>> > >>>>> > >>>>> > >>>>> static void stop_substream(struct uac_rtd_params *prm) > >>>>> { > >>>>>       unsigned long _flags; > >>>>>       struct snd_pcm_substream *substream; > >>>>> > >>>>>       substream = prm->ss; > >>>>>       if (substream) { > >>>>>           snd_pcm_stream_lock_irqsave(substream, _flags); > >>>>>           if (snd_pcm_running(substream)) > >>>>>               // TODO - correct handling for playback substream? > >>>>>               snd_pcm_stop(substream, SNDRV_PCM_STATE_DRAINING); > >>>>>           snd_pcm_stream_unlock_irqrestore(substream, _flags); > >>>>>       } > >>>>> } > >>>>> > >>>>> For setup I found calling snd_pcm_stop(substream, SNDRV_PCM_STATE_SETUP) > >>>>> (https://elixir.bootlin.com/linux/latest/source/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c#L63) > >>>>> > >>>>>    Or for both capture and playback using SNDRV_PCM_STATE_DISCONNECTED > >>>>> (https://elixir.bootlin.com/linux/latest/source/sound/core/pcm.c#L1103). > >>>>> > >>>>> Or perhaps using snd_pcm_dev_disconnect(dev) or snd_pcm_drop(substream)? > >>>>> > >>>>> Please what is the recommended way? > >>>>> > >>>> > >>>> Please can I ask for expert view on this issue? E.g. in SoX stopping the > >>>> stream with SNDRV_PCM_STATE_SETUP/SNDRV_PCM_STATE_DRAINING does not stop > >>>> the application, while with SNDRV_PCM_STATE_DISCONNECTED SoX exits with > >>>> non-recoverable status. I am considering implementing both methods and > >>>> letting users choose their suitable snd_pcm_stop operation (none > >>>> (default)/SETUP-DRAINING/DISCONNECTED) for the two events (host > >>>> playback/capture stop, cable disconnection) with a configfs param. Would > >>>> this make sense? > >>> > >>> The disconnection state is unrecoverable. It's expected that the > >>> device will be freed and cannot be reused. > >>> > >>> If you expect to keep the PCM device, we should probably introduce a > >>> new function which puts the device to the SNDRV_PCM_STATE_OPEN > >>> state. In this state, all I/O routines will return -EBADFD for the > >>> applications, so they should close or re-initialize the PCM device > >>> completely. > >>> > >>> https://elixir.bootlin.com/linux/latest/source/sound/core/pcm_native.c#L794 > >>> > >> > >> The fact is that after closing the USB host can re-open the device > >> with different samplerate (and perhaps later on with different > >> channels count/sample size). That would hint at the need to > >> re-initialize the gadget side before opening anyway. > >> > >> As of keeping the device - it's likely some use cases would prefer > >> keeping the device, to minimize the operations needed to react to the > >> host-side playback/capture start. > >> > >> A function you describe would make sense for this. IMO from the gadget > >> POW there is no difference between the host stopping playback/capture > >> and cable disconnection, in both cases the data stream is stopped and > >> next stream can have entirely different parameters. Maybe the gadget > >> configfs parameter could only toggle between no action (i.e. current > >> situation) and the new alsa function stopping the stream. > >> > >> Jaroslav, please can you draft such a function? Perhaps both changes > >> could make it to 5.17. > > > > (Sorry for the delayed response, as I've been on vacation and now > > catching up the huge pile of backlogs...) > > > > About the change to keep PCM OPEN state: I'm afraid that the > > disconnection in the host side may happen at any time, and keeping the > > state OPEN would confuse the things if the host is indeed > > unrecoverable. > > I don't think so. The SNDRV_PCM_IOCTL_HW_PARAMS must be issued by the > application (in the PCM_OPEN state) and if the USB bus connection is > no longer active, it may fail. We can distinguish between host -> > device disconnection and device -> host one. It is not really a > similar thing. Well, I don't know whether we have a proper protocol to downgrade the state from RUNNING to OPEN. Currently the valid state transition seems to be RUNNING -> SETUP, XRUN, or DISCONNECTED. So, if any, this might be a two-step procedure. thanks, Takashi