On Thu, 05 Nov 2020 15:24:37 +0100, Jonas Holmberg wrote: > > On Wed, Nov 04, 2020 at 02:49:56PM +0100, Jonas Holmberg wrote: > > Set the status tstamp field so that it can be accessed with > > snd_pcm_status_get_htstamp(). > > > > Signed-off-by: Jonas Holmberg <jonashg@xxxxxxxx> > > --- > > src/pcm/pcm_ioplug.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/src/pcm/pcm_ioplug.c b/src/pcm/pcm_ioplug.c > > index a437ca32..9b1b8ac3 100644 > > --- a/src/pcm/pcm_ioplug.c > > +++ b/src/pcm/pcm_ioplug.c > > @@ -115,6 +115,7 @@ static int snd_pcm_ioplug_status(snd_pcm_t *pcm, snd_pcm_status_t * status) > > snd_pcm_ioplug_hw_ptr_update(pcm); > > status->state = io->data->state; > > status->trigger_tstamp = io->trigger_tstamp; > > + gettimestamp(&status->tstamp, pcm->tstamp_type); > > status->avail = snd_pcm_mmap_avail(pcm); > > status->avail_max = io->avail_max; > > return 0; > > -- > > 2.26.2 > > > > Is there a reason that the tstamp field of snd_pcm_ioplug_status() is > always 0? I assumed that it was an oversight/bug so this patch sets it > so that applications can read it with snd_pcm_status_get_htstamp(). I > have tested it and it seems to work well. I guess it's an oversight. It's one of few places where the no real hardware slave PCM is present, and the other one (null plugin) already set it. Also maybe cause snd_pcm_htimestamp() worked without this change; it's updating the timstamp with a different code path. In anyway, I applied your patch now. Thanks! Takashi
