Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp419308pxv; Fri, 9 Jul 2021 00:48:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFLKVIkCkTiqhcqdNzg15APVMAp2vwt53dI3oIfkPanmTpKI9HvK56lvUwfsK5M38yIPha X-Received: by 2002:a5e:9602:: with SMTP id a2mr27962406ioq.146.1625816918582; Fri, 09 Jul 2021 00:48:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625816918; cv=none; d=google.com; s=arc-20160816; b=L3hc3an3gFp7nFSgVVdFTjgv7KaD8wcF+0xnyz47tn7Obi9ImU80fvw7d6drf4nITW 8tYOpjqo6vghC5ZH0DlReA6b9xbWmq8nYGbgUU1LMM94SCQbqugWyAQ6CAJ0Cmq47C+L pZzp1SWdGTjKVmXqZE7lshFFU9IaC5C2ayElVL/9eIkm7nnE0Dq4ISiJ5/KMx3f8rksf dMYMtzk3IR9xXqvYeNJlzGqQ0mPz78EClpBFWgZNR0rsp7hinFvaDTcDNEVO3IClou8O yT/tX0LHD3qrxGbU6tCcSEVW1/22j/7wE8rURD8AKESq0ZIeJxk6CKvaMiOq5+y5ofb7 RZpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date:dkim-signature:dkim-signature; bh=+qYYZCbYZFeVvNX8WUSoJkZi53ZkOf+6w3wV4SkwAN0=; b=RIBWdUnKWwXuLwuE2f43duWntvt+6FrSjmZ3Iur/+QUHpRCNEP+DE59+pLVlwOX5n0 e1CLtsHSKTpam/mzDJl8NWSfLUABAkDmjL0k/nCAlQQVSVNtv+XtJzX7WWwEEuvSfVKR qeWhDiEO6c6ShTesPogWr6sNE8uyNxa8wf47DlU/XdF4xfDXZAfzz/jp2yLq3jNp3SXU qgnUYhrx4kYVWg2nSAXpsCqL4l8456VdzTaKWQN3wTwei06OZk/O1Z/ViHwBV1/3PPts p69s3XP22xBT3SnJ2qK4JaRp3cInQlmpUZB58u0TlY6QH+vxz7m36uABT1wV/OuyRsbF 8R7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=iMOw38P7; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=LHkJFSTz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s13si5675959jaj.54.2021.07.09.00.48.08; Fri, 09 Jul 2021 00:48:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=iMOw38P7; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=LHkJFSTz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231236AbhGIHuU (ORCPT + 99 others); Fri, 9 Jul 2021 03:50:20 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:52382 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230269AbhGIHuU (ORCPT ); Fri, 9 Jul 2021 03:50:20 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 70E7D20267; Fri, 9 Jul 2021 07:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1625816856; 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=+qYYZCbYZFeVvNX8WUSoJkZi53ZkOf+6w3wV4SkwAN0=; b=iMOw38P7hWmAhJ2ERn2KmKkx1lDkXP3j7DTKMp+0r48SVxt/ITOuE61SmBZUNHQm9Nbw/S YKJV3qC8AahobYDvbM9ggFb4NBnwOv1XCBsG99poiIeSmBeQxlPLvT8ZxoG/U3nEtriwUA NzVD9tZ7F8R5n1xerjR7j7nWPckHos4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1625816856; 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=+qYYZCbYZFeVvNX8WUSoJkZi53ZkOf+6w3wV4SkwAN0=; b=LHkJFSTzhvp/jAwrhD249RovXTAGMQ2/mfoEafVHKd1hixRbgODozY2fukelUoqbLlvk9G IAcVdnKZaGaK6kBA== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 5D2A2A3B9B; Fri, 9 Jul 2021 07:47:36 +0000 (UTC) Date: Fri, 09 Jul 2021 09:47:36 +0200 Message-ID: From: Takashi Iwai To: Robert Lee Cc: Jaroslav Kysela , vkoul@kernel.org, tiwai@suse.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, carterhsu@google.com, zxinhui@google.com, bubblefang@google.com Subject: Re: [Patch v2] ALSA: compress: allow to leave draining state when pausing in draining In-Reply-To: References: <20210708020815.3489365-1-lerobert@google.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=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 09 Jul 2021 04:08:29 +0200, Robert Lee wrote: > > Jaroslav Kysela 於 2021年7月8日 週四 下午10:53寫道: > > > > On 08. 07. 21 15:47, Robert Lee wrote: > > > Hi Takashi, > > > > > > It is a little complex to describe the design in detail, but try to > > > explain simply > > > what issue we meet. > > > > > > If w/o the change, after user resumes from the pause, our system would call > > > snd_compr_drain() or snd_compr_partial_drain() again after it returns from > > > previous drain (when EOF reaches). Then it will block in this drain and no one > > > wake it up because EOF has already reached. I add this change to return from > > > the previous drain. > > > > It looks like that the driver does not call snd_compr_drain_notify() so the > > state is not updated to SETUP on EOF. > > > We indeed call snd_compr_drain_notify() on EOF, but after return from > wait_for _drain there is another drain again immediately. > Looks like the system queue some states change on user space and need > to drain again after resume from pause. > I suppose there is different design on user space so I add the hook to > handle diffent usage. Right, the previous drain-in-pause implementation was purely in the kernel side, and user-space didn't change much; after resuming from the pause, the driver resumes exactly to the same state before the pause (i.e. start draining again). The difference sounds similar like the suspend/resume scheme; some does resume by itself to the previous state while some requires the explicit action. > > > Actually, I am wondering how the pause-during-drain can keep the state in > > > DRAINING. It should have a different design. :) > > > > I already proposed to add a new state (because it's a new state), but the > > conservative way was elected to avoid user space changes. Yes, the primary concern is that the compress API uses the very same state like PCM, and if we extend PCM state, it'll be a much larger problem. And, even if we change the state to compress-only, it's still an ABI incompatibility, and it has to be carefully handled not to break the existing application (e.g. expose the new state only when the application is really ready to handle -- introducing a new ioctl for state or introduce a new ioctl like SNDRV_PCM_IOCTL_USER_PVERSION that informs the ABI version the user-space understands). Takashi