* [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type @ 2014-07-08 14:52 Mark Brown 2014-07-09 13:38 ` Takashi Iwai 0 siblings, 1 reply; 7+ messages in thread From: Mark Brown @ 2014-07-08 14:52 UTC (permalink / raw) To: Jaroslav Kysela, Takashi Iwai; +Cc: alsa-devel, Daniel Thompson, Mark Brown From: Mark Brown <broonie@linaro.org> For applications which need to synchronise with external timebases such as broadcast TV applications the kernel monotonic time is not optimal as it includes adjustments from NTP and so may still include discontinuities due to that. A raw monotonic time which does not include any adjustments is available in the kernel from getrawmonotonic() so provide userspace with a new timestamp type SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW which provides timestamps based on this as an option. Reported-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> --- include/sound/asound.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/sound/asound.h b/include/sound/asound.h index 1774a5c..9061cdd 100644 --- a/include/sound/asound.h +++ b/include/sound/asound.h @@ -457,7 +457,8 @@ struct snd_xfern { enum { SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY = 0, /* gettimeofday equivalent */ SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, /* posix_clock_monotonic equivalent */ - SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, + SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW, /* monotonic_raw (no NTP) */ + SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW, }; /* channel positions */ -- 2.0.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type 2014-07-08 14:52 [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type Mark Brown @ 2014-07-09 13:38 ` Takashi Iwai 2014-07-09 19:40 ` Clemens Ladisch 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2014-07-09 13:38 UTC (permalink / raw) To: Mark Brown; +Cc: alsa-devel, Mark Brown, Daniel Thompson At Tue, 8 Jul 2014 16:52:32 +0200, Mark Brown wrote: > > From: Mark Brown <broonie@linaro.org> > > For applications which need to synchronise with external timebases such > as broadcast TV applications the kernel monotonic time is not optimal as > it includes adjustments from NTP and so may still include discontinuities > due to that. A raw monotonic time which does not include any adjustments > is available in the kernel from getrawmonotonic() so provide userspace with > a new timestamp type SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW which provides > timestamps based on this as an option. > > Reported-by: Daniel Thompson <daniel.thompson@linaro.org> > Signed-off-by: Mark Brown <broonie@linaro.org> Currently, the timestamp mode is set implicitly in alsa-lib pcm_hw.c: - When kernel PCM protocol version is high enough, alsa-lib hw prefers the monotonic always (if available), then set pcm->monotonic = 1. - Application can ask whether the current timestamp is monotonic or not via snd_pcm_hw_params_is_monotonic(). So, only adding the flag above doesn't suffice. If we need to add a new mode, the API has to be extended as well. But how? The current API assumes that the monotonic mode was already determined before hw_params. We may add a set of new hw_params get and set calls for tstamp mode while keeping the old API. This would be one option. Another option would be to add a new PCM open flag SND_PCM_TSTAMP_MONOTONIC_RAW, and snd_pcm_hw_params_is_monotonic_raw() function. The latter is easier (a simpler addition), while the former is more extensible to newer formats in future. Comments? (I guess tinyalsa has a different story, but let's align genuine alsa-lib first.) Takashi > --- > include/sound/asound.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/sound/asound.h b/include/sound/asound.h > index 1774a5c..9061cdd 100644 > --- a/include/sound/asound.h > +++ b/include/sound/asound.h > @@ -457,7 +457,8 @@ struct snd_xfern { > enum { > SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY = 0, /* gettimeofday equivalent */ > SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, /* posix_clock_monotonic equivalent */ > - SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, > + SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW, /* monotonic_raw (no NTP) */ > + SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW, > }; > > /* channel positions */ > -- > 2.0.0 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type 2014-07-09 13:38 ` Takashi Iwai @ 2014-07-09 19:40 ` Clemens Ladisch 2014-07-10 10:22 ` Takashi Iwai 2014-07-10 15:10 ` Pierre-Louis Bossart 0 siblings, 2 replies; 7+ messages in thread From: Clemens Ladisch @ 2014-07-09 19:40 UTC (permalink / raw) To: Takashi Iwai, Mark Brown; +Cc: alsa-devel, Daniel Thompson, Mark Brown Takashi Iwai wrote: > Currently, the timestamp mode is set implicitly in alsa-lib pcm_hw.c: > - When kernel PCM protocol version is high enough, alsa-lib hw prefers > the monotonic always (if available), then set pcm->monotonic = 1. > - Application can ask whether the current timestamp is monotonic or > not via snd_pcm_hw_params_is_monotonic(). > So, only adding the flag above doesn't suffice. If we need to add a > new mode, the API has to be extended as well. > > But how? The current API assumes that the monotonic mode was already > determined before hw_params. We may add a set of new hw_params get > and set calls for tstamp mode while keeping the old API. This would > be one option. Another option would be to add a new PCM open flag > SND_PCM_TSTAMP_MONOTONIC_RAW, and snd_pcm_hw_params_is_monotonic_raw() > function. The latter is easier (a simpler addition), while the former > is more extensible to newer formats in future. These timestamps cannot be handled by hardware drivers; they are always read by the ALSA framework, in software. Furthermore, switching between MONOTONIC and MONOTONIC_RAW is possible at any time. Therefore, the timestamp mode should be made a part of sw_params; just add a field named tstamp_mode ... Regards, Clemens ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type 2014-07-09 19:40 ` Clemens Ladisch @ 2014-07-10 10:22 ` Takashi Iwai 2014-07-10 15:10 ` Pierre-Louis Bossart 1 sibling, 0 replies; 7+ messages in thread From: Takashi Iwai @ 2014-07-10 10:22 UTC (permalink / raw) To: Clemens Ladisch; +Cc: alsa-devel, Mark Brown, Daniel Thompson, Mark Brown At Wed, 09 Jul 2014 21:40:02 +0200, Clemens Ladisch wrote: > > Takashi Iwai wrote: > > Currently, the timestamp mode is set implicitly in alsa-lib pcm_hw.c: > > - When kernel PCM protocol version is high enough, alsa-lib hw prefers > > the monotonic always (if available), then set pcm->monotonic = 1. > > - Application can ask whether the current timestamp is monotonic or > > not via snd_pcm_hw_params_is_monotonic(). > > So, only adding the flag above doesn't suffice. If we need to add a > > new mode, the API has to be extended as well. > > > > But how? The current API assumes that the monotonic mode was already > > determined before hw_params. We may add a set of new hw_params get > > and set calls for tstamp mode while keeping the old API. This would > > be one option. Another option would be to add a new PCM open flag > > SND_PCM_TSTAMP_MONOTONIC_RAW, and snd_pcm_hw_params_is_monotonic_raw() > > function. The latter is easier (a simpler addition), while the former > > is more extensible to newer formats in future. > > These timestamps cannot be handled by hardware drivers; they are always > read by the ALSA framework, in software. Furthermore, switching between > MONOTONIC and MONOTONIC_RAW is possible at any time. Therefore, the > timestamp mode should be made a part of sw_params; just add a field > named tstamp_mode ... Sounds reasonable. I'll respin the kernel patches as well. Takashi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type 2014-07-09 19:40 ` Clemens Ladisch 2014-07-10 10:22 ` Takashi Iwai @ 2014-07-10 15:10 ` Pierre-Louis Bossart 2014-07-10 15:33 ` Takashi Iwai 1 sibling, 1 reply; 7+ messages in thread From: Pierre-Louis Bossart @ 2014-07-10 15:10 UTC (permalink / raw) To: Clemens Ladisch, Takashi Iwai, Mark Brown Cc: alsa-devel, Daniel Thompson, Mark Brown On 7/9/14, 2:40 PM, Clemens Ladisch wrote: > Takashi Iwai wrote: >> Currently, the timestamp mode is set implicitly in alsa-lib pcm_hw.c: >> - When kernel PCM protocol version is high enough, alsa-lib hw prefers >> the monotonic always (if available), then set pcm->monotonic = 1. >> - Application can ask whether the current timestamp is monotonic or >> not via snd_pcm_hw_params_is_monotonic(). >> So, only adding the flag above doesn't suffice. If we need to add a >> new mode, the API has to be extended as well. >> >> But how? The current API assumes that the monotonic mode was already >> determined before hw_params. We may add a set of new hw_params get >> and set calls for tstamp mode while keeping the old API. This would >> be one option. Another option would be to add a new PCM open flag >> SND_PCM_TSTAMP_MONOTONIC_RAW, and snd_pcm_hw_params_is_monotonic_raw() >> function. The latter is easier (a simpler addition), while the former >> is more extensible to newer formats in future. > > These timestamps cannot be handled by hardware drivers; they are always > read by the ALSA framework, in software. Furthermore, switching between > MONOTONIC and MONOTONIC_RAW is possible at any time. Therefore, the > timestamp mode should be made a part of sw_params; just add a field > named tstamp_mode ... Humm... why would anyone switch modes at run time during playback/capture? I have seen timestamps being used mainly to track that playback/capture is happening as predicted, improve A/V sync or sleep for a predictable time with interrupts disabled (PulseAudio, Android, ChromeOS, etc). NTP adjustments are really adding noise more than information for those usages. I have yet to see a case where the use of those NTP adjustments would matter for userspace, and for now I really don't see the point of making this dynamically configurable as a software parameter. I would personally make this new mode the default. -Pierre ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type 2014-07-10 15:10 ` Pierre-Louis Bossart @ 2014-07-10 15:33 ` Takashi Iwai 2014-07-10 15:38 ` Pierre-Louis Bossart 0 siblings, 1 reply; 7+ messages in thread From: Takashi Iwai @ 2014-07-10 15:33 UTC (permalink / raw) To: Pierre-Louis Bossart Cc: alsa-devel, Mark Brown, Clemens Ladisch, Daniel Thompson, Mark Brown At Thu, 10 Jul 2014 10:10:56 -0500, Pierre-Louis Bossart wrote: > > On 7/9/14, 2:40 PM, Clemens Ladisch wrote: > > Takashi Iwai wrote: > >> Currently, the timestamp mode is set implicitly in alsa-lib pcm_hw.c: > >> - When kernel PCM protocol version is high enough, alsa-lib hw prefers > >> the monotonic always (if available), then set pcm->monotonic = 1. > >> - Application can ask whether the current timestamp is monotonic or > >> not via snd_pcm_hw_params_is_monotonic(). > >> So, only adding the flag above doesn't suffice. If we need to add a > >> new mode, the API has to be extended as well. > >> > >> But how? The current API assumes that the monotonic mode was already > >> determined before hw_params. We may add a set of new hw_params get > >> and set calls for tstamp mode while keeping the old API. This would > >> be one option. Another option would be to add a new PCM open flag > >> SND_PCM_TSTAMP_MONOTONIC_RAW, and snd_pcm_hw_params_is_monotonic_raw() > >> function. The latter is easier (a simpler addition), while the former > >> is more extensible to newer formats in future. > > > > These timestamps cannot be handled by hardware drivers; they are always > > read by the ALSA framework, in software. Furthermore, switching between > > MONOTONIC and MONOTONIC_RAW is possible at any time. Therefore, the > > timestamp mode should be made a part of sw_params; just add a field > > named tstamp_mode ... > > Humm... why would anyone switch modes at run time during > playback/capture? I have seen timestamps being used mainly to track that > playback/capture is happening as predicted, improve A/V sync or sleep > for a predictable time with interrupts disabled (PulseAudio, Android, > ChromeOS, etc). NTP adjustments are really adding noise more than > information for those usages. I have yet to see a case where the use of > those NTP adjustments would matter for userspace, and for now I really > don't see the point of making this dynamically configurable as a > software parameter. I would personally make this new mode the default. As Clemens already pointed, if the application itself refers to the timestamp and compares with the own timestamp by CLOCK_MONOTONIC, using CLOCK_MONOTONIC_RAW would break. So we cannot replace it with CLOCK_MONOTONIC_RAW silently, unfortunately. Takashi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type 2014-07-10 15:33 ` Takashi Iwai @ 2014-07-10 15:38 ` Pierre-Louis Bossart 0 siblings, 0 replies; 7+ messages in thread From: Pierre-Louis Bossart @ 2014-07-10 15:38 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, Mark Brown, Clemens Ladisch, Daniel Thompson, Mark Brown On 7/10/14, 10:33 AM, Takashi Iwai wrote: > At Thu, 10 Jul 2014 10:10:56 -0500, > Pierre-Louis Bossart wrote: >> >> On 7/9/14, 2:40 PM, Clemens Ladisch wrote: >>> Takashi Iwai wrote: >>>> Currently, the timestamp mode is set implicitly in alsa-lib pcm_hw.c: >>>> - When kernel PCM protocol version is high enough, alsa-lib hw prefers >>>> the monotonic always (if available), then set pcm->monotonic = 1. >>>> - Application can ask whether the current timestamp is monotonic or >>>> not via snd_pcm_hw_params_is_monotonic(). >>>> So, only adding the flag above doesn't suffice. If we need to add a >>>> new mode, the API has to be extended as well. >>>> >>>> But how? The current API assumes that the monotonic mode was already >>>> determined before hw_params. We may add a set of new hw_params get >>>> and set calls for tstamp mode while keeping the old API. This would >>>> be one option. Another option would be to add a new PCM open flag >>>> SND_PCM_TSTAMP_MONOTONIC_RAW, and snd_pcm_hw_params_is_monotonic_raw() >>>> function. The latter is easier (a simpler addition), while the former >>>> is more extensible to newer formats in future. >>> >>> These timestamps cannot be handled by hardware drivers; they are always >>> read by the ALSA framework, in software. Furthermore, switching between >>> MONOTONIC and MONOTONIC_RAW is possible at any time. Therefore, the >>> timestamp mode should be made a part of sw_params; just add a field >>> named tstamp_mode ... >> >> Humm... why would anyone switch modes at run time during >> playback/capture? I have seen timestamps being used mainly to track that >> playback/capture is happening as predicted, improve A/V sync or sleep >> for a predictable time with interrupts disabled (PulseAudio, Android, >> ChromeOS, etc). NTP adjustments are really adding noise more than >> information for those usages. I have yet to see a case where the use of >> those NTP adjustments would matter for userspace, and for now I really >> don't see the point of making this dynamically configurable as a >> software parameter. I would personally make this new mode the default. > > As Clemens already pointed, if the application itself refers to the > timestamp and compares with the own timestamp by CLOCK_MONOTONIC, > using CLOCK_MONOTONIC_RAW would break. So we cannot replace it with > CLOCK_MONOTONIC_RAW silently, unfortunately. ok, fine, it's a different mode then. That still doesn't clarify who would ever switch modes dynamically while streaming data. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-07-10 15:38 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-08 14:52 [PATCH] alsa-lib: Provide a CLOCK_MONOTONIC_RAW timestamp type Mark Brown 2014-07-09 13:38 ` Takashi Iwai 2014-07-09 19:40 ` Clemens Ladisch 2014-07-10 10:22 ` Takashi Iwai 2014-07-10 15:10 ` Pierre-Louis Bossart 2014-07-10 15:33 ` Takashi Iwai 2014-07-10 15:38 ` Pierre-Louis Bossart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.