On Thu, 16 Nov 2017 19:11:37 +0100,
Pierre-Louis Bossart wrote:
>
> On 11/16/17 8:48 AM, Takashi Iwai wrote:
> > On Thu, 16 Nov 2017 13:43:57 +0100,
> > Henrik Eriksson wrote:
> >>
> >> Hello
> >>
> >> This reverts a change that was part of a larger commit. That change
> >> broke timestamps in some application code for us as outlined in the log,
> >> and reverting it obviously fixes this. Since the original change did
> >> not explain why the behaviour was modified I can't speak for the effects
> >> on that use case.
> >>
> >> Regards,
> >> /henrik
> >>> 8------------------------------------------------------8<
> >> Commit 3179f62001880e588e229db3006a59ad87b7792a ("ALSA: core: add
> >> .get_time_info") made an undocumented change to the behaviour of the
> >> PCM runtime tstamp. Prior to this change the tstamp was not updated
> >> by snd_pcm_update_hw_ptr0() unless the hw ptr had moved, after this
> >> change the tstamp is always updated.
> >>
> >> For an application, using alsa-lib, doing snd_pcm_readi() followed by
> >> snd_pcm_status() to estimate the age of the read samples by subtracting
> >> status->avail * [sample rate] from status->tstamp this change degraded
> >> the accuracy of that estimate on devices where the pcm hw does not
> >> provide a granular hw pointer. On a device using
> >> soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
> >> DMA_RESIDUE_GRANULARITY_DESCRIPTOR the accuracy of the estimate depended
> >> on the latency between the PCM hw completing a period and when the
> >> driver called snd_pcm_period_elapsed() to notify ALSA core, typically
> >> determined by interrupt handling latency. After this change the
> >> accuracy of the estimate is determined by the latency between the PCM hw
> >> completing a period and the application calling snd_pcm_status(),
> >> determined by the scheduling of the application process.
> >>
> >> Revert the part of commit 3179f62001880e588e229db3006a59ad87b7792a
> >> ("ALSA: core: add .get_time_info") that changed be behaviour of
> >> snd_pcm_update_hw_ptr0() when the PCM hw pointer has not moved.
> >>
> >> Fixes: 3179f6200188 ("ALSA: core: add .get_time_info")
> >> Signed-off-by: Henrik Eriksson <henrik.eriksson@xxxxxxxx>
> >
> > So this is a regression and we need to address it.
> >
> > I *guess* that the reason to update tstamp event at the same hwptr is
> > that now we can get a more fine-grained tstamp. OTOH, we have to
> > avoid the regression by that.
> >
> > What about the (untested) patch like below? It skips the tstamp
> > update as default but follows the new standard when a better tstamp
> > mode is deployed.
>
> update_audio_tstamp() only updates the audio timestamp when the type
> is DEFAULT already, but indeed update runtime->status->tstamp is
> updated unconditionally.
>
> I have a bit of heartburn with the suggested solutions because the
> delay can change even with the same hw_ptr. Not updating the
> timestamps would be going back to the days where timing updates was
> dependent on DMA granularity.
>
> Maybe we could make the tstamp update dependent on a change in
> audio_tstamp, e.g.
>
>
> diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
> index a93a4235a332..b606f3ea7a17 100644
> --- a/sound/core/pcm_lib.c
> +++ b/sound/core/pcm_lib.c
> @@ -248,8 +248,10 @@ static void update_audio_tstamp(struct
> snd_pcm_substream *substream,
> runtime->rate);
> *audio_tstamp = ns_to_timespec(audio_nsecs);
> }
> - runtime->status->audio_tstamp = *audio_tstamp;
> - runtime->status->tstamp = *curr_tstamp;
> + if (runtime->status->audio_tstamp != *audio_tstamp) {
> + runtime->status->audio_tstamp = *audio_tstamp;
> + runtime->status->tstamp = *curr_tstamp;
> + }
OK for me as long as it works.
Henrik?
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
