From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH RFC 2/9] ALSA: core: allow for trigger_tstamp snapshot in .trigger Date: Wed, 10 Dec 2014 20:20:33 +0100 Message-ID: References: <1418077426-8309-1-git-send-email-pierre-louis.bossart@linux.intel.com> <1418077426-8309-3-git-send-email-pierre-louis.bossart@linux.intel.com> <5488814B.5030406@linux.intel.com> <5488945A.8010208@linux.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 173382605A3 for ; Wed, 10 Dec 2014 20:20:34 +0100 (CET) In-Reply-To: <5488945A.8010208@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Wed, 10 Dec 2014 12:43:38 -0600, Pierre-Louis Bossart wrote: > > > >>>> + int trigger_tstamp_pending_update; /* trigger timestamp being updated from initial estimate */ > >>> > >>> This isn't used at all in this patch. I found it being used in the > >>> later usb-audio patch. If it's the only place, can't it be rather put > >>> locally to usb-audio object instead of the common pcm runtime? > >> > >> It's not limited to USB. We have upcoming hardware where the > >> trigger_tstamp will only be determined with a delay due to IPC. USB is > >> just an example of a common pattern where the trigger_tstamp will be > >> known for sure after a couple of ms. > > > > Well, the question is whether this *must* be put in the common place. > > In other words, will this field be referred in the common PCM code? > > If not, it should be recorded rather locally. > > well i wasn't sure of what to do here: > 1. we can leave the low-lever driver update the trigger_tstamp on its > own, and then this field is not needed at the core level, but the core > or the application will not be notified that an update is pending > 2. or we use this field to let the core know, and possibly let userspace > know that the trigger will be updated shortly. However, I didn't find an > existing mechanism to notify userspace that the new trigger_tstamp is > dirty and has changed so the use of this field is indeed incomplete for now. We're extending the status struct in anyway, so can we put a (bit) flag somewhere indicating the behavior? Takashi