Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH RFC 2/9] ALSA: core: allow for trigger_tstamp snapshot in .trigger
Date: Wed, 10 Dec 2014 11:22:19 -0600	[thread overview]
Message-ID: <5488814B.5030406@linux.intel.com> (raw)
In-Reply-To: <s5htx13mpoy.wl-tiwai@suse.de>

Thanks for the review.

On 12/10/14, 10:31 AM, Takashi Iwai wrote:
> At Mon,  8 Dec 2014 16:23:39 -0600,
> Pierre-Louis Bossart wrote:
>>
>> Don't use generic snapshot of trigger_tstamp if low-level driver or
>> hardware can get a more precise value for better audio/system time
>> synchronization.
>>
>> Also add definitions for delayed updates if actual trigger tstamp
>> can be only be provided after a delay due to hardware constraints.
>>
>> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
>> ---
>>   include/sound/pcm.h     | 2 ++
>>   sound/core/pcm_native.c | 6 +++++-
>>   2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/sound/pcm.h b/include/sound/pcm.h
>> index 1e7f74a..83c669f 100644
>> --- a/include/sound/pcm.h
>> +++ b/include/sound/pcm.h
>> @@ -281,6 +281,8 @@ struct snd_pcm_runtime {
>>   	/* -- Status -- */
>>   	struct snd_pcm_substream *trigger_master;
>>   	struct timespec trigger_tstamp;	/* trigger timestamp */
>> +	int trigger_tstamp_latched;     /* trigger timestamp latched in low-level driver/hardware */
>
> Better to use bool nowadays.

ok

>
>> +	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.

>
>>   	int overrange;
>>   	snd_pcm_uframes_t avail_max;
>>   	snd_pcm_uframes_t hw_ptr_base;	/* Position at buffer restart */
>> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
>> index 5dc83fb..37a7137 100644
>> --- a/sound/core/pcm_native.c
>> +++ b/sound/core/pcm_native.c
>> @@ -806,10 +806,14 @@ static int snd_pcm_channel_info_user(struct snd_pcm_substream *substream,
>>   static void snd_pcm_trigger_tstamp(struct snd_pcm_substream *substream)
>>   {
>>   	struct snd_pcm_runtime *runtime = substream->runtime;
>> +
>>   	if (runtime->trigger_master == NULL)
>>   		return;
>>   	if (runtime->trigger_master == substream) {
>> -		snd_pcm_gettime(runtime, &runtime->trigger_tstamp);
>> +		if (runtime->trigger_tstamp_latched == 0)
>> +			snd_pcm_gettime(runtime, &runtime->trigger_tstamp);
>> +		else
>> +			runtime->trigger_tstamp_latched = 0;
>
> IMO, it's better to clear the flat at the beginning of PCM trigger
> commonly.  Looking at the later patch, you clear in each driver's
> callback.  This should be moved into the common place.

I must admit I don't really understand the logic of all the _pre and 
_post operations. Did you mean clearing this field in snd_pcm_do_start()?


>
> thanks,
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

  reply	other threads:[~2014-12-10 17:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08 22:23 [PATCH RFC 0/9] audio timestamping evolutions Pierre-Louis Bossart
2014-12-08 22:23 ` [PATCH RFC 1/9] ALSA: core: don't override timestamp unconditionally Pierre-Louis Bossart
2014-12-08 22:23 ` [PATCH RFC 2/9] ALSA: core: allow for trigger_tstamp snapshot in .trigger Pierre-Louis Bossart
2014-12-10 16:31   ` Takashi Iwai
2014-12-10 17:22     ` Pierre-Louis Bossart [this message]
2014-12-10 17:35       ` Takashi Iwai
2014-12-10 18:43         ` Pierre-Louis Bossart
2014-12-10 19:20           ` Takashi Iwai
2014-12-08 22:23 ` [PATCH RFC 3/9] ALSA: hda: read trigger_timestamp immediately after starting DMA Pierre-Louis Bossart
2014-12-08 22:23 ` [PATCH RFC 4/9] ALSA: usb: update trigger timestamp on first non-zero URB submitted Pierre-Louis Bossart
2014-12-08 22:23 ` [PATCH RFC 5/9] ALSA: core: selection of audio_tstamp type and accuracy reports Pierre-Louis Bossart
2014-12-10 16:35   ` Takashi Iwai
2014-12-10 17:27     ` Pierre-Louis Bossart
2014-12-10 17:39       ` Takashi Iwai
2014-12-10 20:08         ` Takashi Iwai
2014-12-10 21:48           ` Pierre-Louis Bossart
2014-12-10 22:27             ` Takashi Iwai
2014-12-10 23:04               ` Pierre-Louis Bossart
2014-12-11  5:54                 ` Takashi Iwai
2014-12-12  2:36                   ` Pierre-Louis Bossart
2014-12-12  8:37                     ` Takashi Iwai
2014-12-12 15:20                       ` Pierre-Louis Bossart
2014-12-14 15:03                         ` Takashi Iwai
2014-12-16 14:01               ` Tim Cussins
2014-12-08 22:23 ` [PATCH RFC 6/9] ALSA: core: pass audio tstamp config from userspace Pierre-Louis Bossart
2014-12-10 17:28   ` Takashi Iwai
2014-12-10 17:35     ` Pierre-Louis Bossart
2014-12-10 17:40       ` Takashi Iwai
2014-12-08 22:23 ` [PATCH RFC 7/9] ALSA: core: pass audio tstamp config from userspace in compat mode Pierre-Louis Bossart
2014-12-08 22:23 ` [PATCH RFC 8/9] ALSA: core: replace .wall_clock by .get_time_info Pierre-Louis Bossart
2014-12-08 22:23 ` [PATCH RFC 9/9] ALSA: hda: replace .wallclock " Pierre-Louis Bossart
2014-12-10  4:40 ` [PATCH RFC 0/9] audio timestamping evolutions Raymond Yau
2014-12-10 14:55   ` Pierre-Louis Bossart
2014-12-12  4:55     ` Raymond Yau
2014-12-12 15:28       ` Pierre-Louis Bossart
2014-12-14  3:34         ` Raymond Yau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5488814B.5030406@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox