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=-0.8 required=3.0 tests=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 08BDAC43331 for ; Fri, 27 Mar 2020 08:09:46 +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 8554D20714 for ; Fri, 27 Mar 2020 08:09:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="M7oOsB1Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8554D20714 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 D90B21661; Fri, 27 Mar 2020 09:08:53 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D90B21661 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1585296583; bh=v+8jEl9eJCM0irm6C+weVdyY/2CAdGSEQPRfXb+8rj4=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=M7oOsB1ZwMR/z/2s3XIh9fVle8bavmtBL/MygweZnd2LGfiCfQaZYrF/VkW3wBjn2 bmc9xqWO+RrE0HsnshJ2BDnUaFLyEW+9SruV19rF2WKNCwivFwb9VCj7XIimtTuWTn gXGaSeJACeG4hExTnTSiK91FN8m/5s8ChnFlmbog= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 372A5F80147; Fri, 27 Mar 2020 09:08:53 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 77B89F80158; Fri, 27 Mar 2020 09:08:51 +0100 (CET) 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 7055FF800EA for ; Fri, 27 Mar 2020 09:08:47 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 7055FF800EA X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3FCE3B3A8; Fri, 27 Mar 2020 08:08:46 +0000 (UTC) Date: Fri, 27 Mar 2020 09:08:46 +0100 Message-ID: From: Takashi Iwai To: sylvain.bertrand@gmail.com Subject: Re: sw_params for a direct-ed(dmix) hw pcm In-Reply-To: <20200326200415.GA1321@freedom> References: <20200321155303.GB357@freedom> <20200325174419.GA1224@freedom> <9d986c48-184a-1d6e-4c5b-172a7ecd98a8@perex.cz> <20200326200415.GA1321@freedom> 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, Kai Vehmanen 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 Thu, 26 Mar 2020 21:04:15 +0100, sylvain.bertrand@gmail.com wrote: > > On Thu, Mar 26, 2020 at 03:36:23PM +0100, Jaroslav Kysela wrote: > > I agree. Also, the snd_pcm_direct_sw_params() does nothing, because the > > sw_params are already cached in the pcm structure (see comment). It means > > that the dmix (direct) plugins operates with those cached values. Just set > > sw_params like for any other PCM handle. The dmix uses those values (if > > possible). > > This is the "if possible" which would impacts the way how code should do setup > right, but: > > Let's take the case of a classic plugin "pipeline": > pcm:plug->...->direct::dmix->hw > > >From the top plugin (usually plug) to the direct::plugin, the "sw_params" pcm > op is usually pcm_generic.c:snd_pcm_generic_sw_params which does recurse down. > This recursion down will stop once pcm_direct.c:snd_pcm_direct_sw_params is > reached, then will recurse up, without error. > > But pcm.c:snd_pcm_sw_params will copy anyway the provided sw_params into each > recursed back pcm if the "sw_params" pcm op return no error code, which is the > case. > > Then looking at pcm.c:snd_pcm_sw_params_current, I get those "wrong" sw_params, > then I get no way to know something went wrong. > > Why "wrong", because they may significantly differ from the bottom hw plugin > sw_params which some fields are used to configure the kernel driver. > > for instance, a fast_op status call will recurse down to > pcm_dmix.c:snd_pcm_dmix_status, which will call the hw plugin fast op status > function which will use _its_ tstamp_type field for the ioctl call, but will > "override" the trigger_tstamp field computed with the "wrong" sw_params > tstamp_type! > > It happens that the monotonic_raw and monotonic clocks can have audio > significant difference. Additionally, the other sw_params field might cause > similar issues. The tstamp type handling in dmix is certainly buggy, yes. It should have been restricted with the slave PCM unless it's compatible. Takashi