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=-4.0 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 F220EC4727E for ; Wed, 30 Sep 2020 09:36:12 +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 446F320754 for ; Wed, 30 Sep 2020 09:36:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="l4S3TOTg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 446F320754 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 8A5681770; Wed, 30 Sep 2020 11:35:19 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 8A5681770 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1601458569; bh=8t9is6OjWwxm4PEwAl87y/jIci2O5YskMtyCYuW8V2M=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=l4S3TOTguSTaHjYXFlLZ5dBH8n73QUyx0tce1Ro/IkCXolwZZutwJuwAjWSW88K7N EAykLYZpdY9UWuSAtmz1jMxIqhAPdn1fUs+bmrT4d8IRmscV6heU+4Uyo25cMzQjbV HkNw3msQP87sXt8LRWiboIdrdjLEHBS6WIjukXG4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 23170F801D8; Wed, 30 Sep 2020 11:35:19 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 6294BF801ED; Wed, 30 Sep 2020 11:35:18 +0200 (CEST) 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 4E10AF800DF for ; Wed, 30 Sep 2020 11:35:11 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 4E10AF800DF 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 58224AD73; Wed, 30 Sep 2020 09:35:11 +0000 (UTC) Date: Wed, 30 Sep 2020 11:35:09 +0200 Message-ID: From: Takashi Iwai To: Jaroslav Kysela Subject: Re: [PATCH] ALSA: compress: allow pause and resume during draining In-Reply-To: References: <000c01d69585$228db6b0$67a92410$@samsung.com> <7ba714ce-8b33-1b64-7503-6b155bf43909@perex.cz> <000f01d69603$10573fb0$3105bf10$@samsung.com> 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, khw0178.kim@samsung.com, lgirdwood@gmail.com, kimty@samsung.com, s47.kang@samsung.com, 'Pierre-Louis Bossart' , tiwai@suse.com, vkoul@kernel.org, hmseo@samsung.com, Gyeongtaek Lee , pilsun.jang@samsung.com, tkjung@samsung.com 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, 29 Sep 2020 19:27:17 +0200, Jaroslav Kysela wrote: > > Dne 29. 09. 20 v 9:12 Takashi Iwai napsal(a): > > On Tue, 29 Sep 2020 03:51:35 +0200, > > Gyeongtaek Lee wrote: > >> > >> On 9/28/20 11:35 PM, Pierre-Louis Bossart wrote: > >>> On 9/28/20 6:13 AM, Jaroslav Kysela wrote: > >>>> Dne 28. 09. 20 v 12:50 Gyeongtaek Lee napsal(a): > >>>>> With a stream with low bitrate, user can't pause or resume the stream > >>>>> near the end of the stream because current ALSA doesn't allow it. > >>>>> If the stream has very low bitrate enough to store whole stream into > >>>>> the buffer, user can't do anything except stop the stream and then > >>>>> restart it from the first. > >>>>> If pause and resume is allowed during draining, user experience can be > >>>>> enhanced. > >>>> > >>>> It seems that we need a new state to handle the pause + drain condition for > >>>> this case. > >>>> > >>>> With this proposed change, the pause state in drain is invisible. > >>> > >>> Indeed it's be much nicer to have a new state, e..g > >>> SNDRV_PCM_STATE_DRAINING_PAUSED. > >> Ok. I will add the new state. > >>> > >>> One concern is that states are defined in uapi/sound/asoc.h, so wouldn't > >>> this have impacts on userspace as well? We'd change the value of > >>> SNDRV_PCM_STATE_LAST. > >>> > >> I also agree that adding new state and increase LAST value in the header of uapi > >> could be dangerous. So, I added it to comress_offload.h for now. > >> It could be merged into snd_pcm_state_t in someday with big changes. > >> Could you review the fixed patch below? > > I don't see a big problem to improve the API, but don't forget to increase the > SNDRV_COMPRESS_VERSION, so the user space apps can check for this new behaviour. > > > Hrm, this resulted in rather more complex changes than the original > > patch. It shows that introducing yet another state is no good idea > > for this particular case. > > I don't think so. The states should be isolated and it's clearly a new state > and the resulted code at least gives a commented idea, what's going on. It > seems that the compress driver state is not exported to the user space at the > moment, so I would consider this extension as harmless. We can add this state > to asound.h so the user space can be updated. We may use this state for the > standard PCM devices one day, too. It makes sense to reserve it sooner than later. Well, adding a new state can be cumbersome sometimes. For example, the code like below may hit a segfault out of sudden after the upgrade: const char *states[SNDRV_PCM_STATE_LAST + 1] = { [SNDRV_PCM_STATE_RUNNING] = "running", .... }; printf("current state = %s\n", states[s]); It's not much frequent breakage, but this can give certainly some incompatibilities even in the source code level. That's the reason I'm reluctant to add a new state unless it's a must. As mentioned, the expected application's behavior is just like the normal pause state, either resuming pause or dropping. The only case where a new state would help for application is at most that they may foresee beforehand which state it'll go after the resume, to drain or to running. If this is a must-to-have feature, we can reconsider. > BTW: Offtopic - Why compress code returns EPERM if the state is not correct? > It's not about the permissions. The EBADFD is much better code in this case. Indeed that sounds inconsistent, but I'm afraid it too late to change? Suppose some code already depending on the error code. Who knows... thanks, Takashi