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 4DCE2C433F5 for ; Mon, 3 Jan 2022 12:28:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231603AbiACM2a (ORCPT ); Mon, 3 Jan 2022 07:28:30 -0500 Received: from mail1.perex.cz ([77.48.224.245]:32968 "EHLO mail1.perex.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229586AbiACM2a (ORCPT ); Mon, 3 Jan 2022 07:28:30 -0500 Received: from mail1.perex.cz (localhost [127.0.0.1]) by smtp1.perex.cz (Perex's E-mail Delivery System) with ESMTP id 7C6A4A0040; Mon, 3 Jan 2022 13:28:28 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.perex.cz 7C6A4A0040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perex.cz; s=default; t=1641212908; bh=Xof2WKElXmenIQgFZezAvXYN+P+VCsCATHtA+a2bvEc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=KRmKQznCZUuELuH/1dydU5QM4riOP87XkyvWLGfLAMqOmCYbFCChUcIxL1osbvLP8 OamgAQdnEJByMUdtRYfxFUuCRU8uE1JfowntOXrcF5C/EcJ2ivom7QaXQ1hvZ7yTfB /J9H+EyaqpqrH+lujY1IEJca88xZEKRc5/4C9Ls8= Received: from [192.168.100.98] (unknown [192.168.100.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: perex) by mail1.perex.cz (Perex's E-mail Delivery System) with ESMTPSA; Mon, 3 Jan 2022 13:28:18 +0100 (CET) Message-ID: <581f6464-37ef-9ab6-e7e2-657ad645aa9e@perex.cz> Date: Mon, 3 Jan 2022 13:28:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Correct stopping capture and playback substreams? Content-Language: en-US To: Takashi Iwai , Pavel Hofman Cc: "alsa-devel@alsa-project.org" , Julian Scheel , Jack Pham , "linux-usb@vger.kernel.org" , John Keeping , Ruslan Bilovol , Yunhao Tian , Jerome Brunet References: <448e059f-fbac-66ed-204b-f6f9c2c19212@ivitera.com> <9635d70f-dc12-f9ed-29f5-ce34a1d4b112@ivitera.com> From: Jaroslav Kysela In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org 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. I think that the idea was to avoid to re-build the whole card / device structure for the fixed device allocation. Pavel, if the USB host is not connected to the gadget, where the playback PCM device fails now ? Is the PCM device created or not ? Jaroslav -- Jaroslav Kysela Linux Sound Maintainer; ALSA Project; Red Hat, Inc. 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 03707C433F5 for ; Mon, 3 Jan 2022 12:29:39 +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 AB7F71782; Mon, 3 Jan 2022 13:28:47 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz AB7F71782 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1641212977; bh=wIhk7ar1O0efTb6vP0dBvBL+R2w7keYOCYir4u56IwM=; h=Date:Subject:To:References:From:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mgUa7/drja1NtbY0j+aBuiqB5zTY0DhOYcm8GWbnxCgXtQPHEKYisXZLThhwh5VTl Jbry/vYIKqB3HRhFozyNzabhh8mJvmYSDWd8fbsytHO3g0pj3u34VGlXixMyaEVBkb Rn90fxpzfRTAvjTie97IPc6mq5j+qVoUo5IrbewE= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 46151F800FF; Mon, 3 Jan 2022 13:28:47 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DBC83F80107; Mon, 3 Jan 2022 13:28:43 +0100 (CET) Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 61844F8007E for ; Mon, 3 Jan 2022 13:28:33 +0100 (CET) Received: from mail1.perex.cz (localhost [127.0.0.1]) by smtp1.perex.cz (Perex's E-mail Delivery System) with ESMTP id 7C6A4A0040; Mon, 3 Jan 2022 13:28:28 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.perex.cz 7C6A4A0040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perex.cz; s=default; t=1641212908; bh=Xof2WKElXmenIQgFZezAvXYN+P+VCsCATHtA+a2bvEc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=KRmKQznCZUuELuH/1dydU5QM4riOP87XkyvWLGfLAMqOmCYbFCChUcIxL1osbvLP8 OamgAQdnEJByMUdtRYfxFUuCRU8uE1JfowntOXrcF5C/EcJ2ivom7QaXQ1hvZ7yTfB /J9H+EyaqpqrH+lujY1IEJca88xZEKRc5/4C9Ls8= Received: from [192.168.100.98] (unknown [192.168.100.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: perex) by mail1.perex.cz (Perex's E-mail Delivery System) with ESMTPSA; Mon, 3 Jan 2022 13:28:18 +0100 (CET) Message-ID: <581f6464-37ef-9ab6-e7e2-657ad645aa9e@perex.cz> Date: Mon, 3 Jan 2022 13:28:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Correct stopping capture and playback substreams? Content-Language: en-US To: Takashi Iwai , Pavel Hofman References: <448e059f-fbac-66ed-204b-f6f9c2c19212@ivitera.com> <9635d70f-dc12-f9ed-29f5-ce34a1d4b112@ivitera.com> From: Jaroslav Kysela In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Julian Scheel , "alsa-devel@alsa-project.org" , "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 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. I think that the idea was to avoid to re-build the whole card / device structure for the fixed device allocation. Pavel, if the USB host is not connected to the gadget, where the playback PCM device fails now ? Is the PCM device created or not ? Jaroslav -- Jaroslav Kysela Linux Sound Maintainer; ALSA Project; Red Hat, Inc.