[alsa-devel] POSIX clocks and ALSA
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
-- Heikki Lindholm
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
-- Heikki Lindholm
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
The addition of monolithc clock isn't hard, but it's an API change that involves with the kernel-side change. So let's do it carefully.
But, honestly, I'm still concerned what to be done first. Shouldn't we discuss about the usefulness of the timestamp at first? That is, whether the current form (API, implementation) is the best or not, what kind of user would be, and how it's used. So far, this feature is "simply there"...
thanks,
Takashi
On Mon, 26 Nov 2007, Takashi Iwai wrote:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
I cannot find it quickly, but you may check alsa-devel archives.
The addition of monolithc clock isn't hard, but it's an API change that involves with the kernel-side change. So let's do it carefully.
But, honestly, I'm still concerned what to be done first. Shouldn't we discuss about the usefulness of the timestamp at first? That is, whether the current form (API, implementation) is the best or not, what kind of user would be, and how it's used. So far, this feature is "simply there"...
The precise timestamps are necessary to keep in sync multiple timing sources. First example if you have multiple cards with different clocks, a code maintaining drifts using an adaptive resampler might be created. We need definitely one master time source. And I think that it is best, if this master timer source can be shared with other unix applications as well (video, scheduling real-time events etc.). So, logically, in my opinion, the best master timer source is the system clock.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
Takashi Iwai kirjoitti:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
The addition of monolithc clock isn't hard, but it's an API change that involves with the kernel-side change. So let's do it carefully.
But, honestly, I'm still concerned what to be done first. Shouldn't we discuss about the usefulness of the timestamp at first? That is, whether the current form (API, implementation) is the best or not, what kind of user would be, and how it's used. So far, this feature is "simply there"...
IMHO the current API definitely isn't the best possible, but nothing better has been available on Linux, so it's a make-do situation. My ideal would be something resembling or even 1:1 copying SGI's media libraries where every media fragment is timestamped with the UST, and the timestamps are the starting time of the media chunk in question instead of ending/sometime after time. The problem with implementing the SGI API on Linux is that AFAICT no Linux supported/available hardware supports such timestamping.
Additionally, it might be nice to be able to add audio clocks as system wide clocks, so, that for example I could tell v4l to use timestamps from an audio clock instead of the system clock.
Allowing clock selection between CLOCK_REALTIME (for backwards compatibility) and CLOCK_MONOTONIC would, however, be a start.
-- Heikki Lindholm
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Takashi Iwai kirjoitti:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
The addition of monolithc clock isn't hard, but it's an API change that involves with the kernel-side change. So let's do it carefully.
But, honestly, I'm still concerned what to be done first. Shouldn't we discuss about the usefulness of the timestamp at first? That is, whether the current form (API, implementation) is the best or not, what kind of user would be, and how it's used. So far, this feature is "simply there"...
IMHO the current API definitely isn't the best possible, but nothing better has been available on Linux, so it's a make-do situation. My ideal would be something resembling or even 1:1 copying SGI's media libraries where every media fragment is timestamped with the UST, and the timestamps are the starting time of the media chunk in question instead of ending/sometime after time. The problem with implementing the SGI API on Linux is that AFAICT no Linux supported/available hardware supports such timestamping.
Unfortunately, we are not using audio "packets" at the moment, but basically, it shouldn't be difficult to implement - think one period == one packet.
Additionally, it might be nice to be able to add audio clocks as system wide clocks, so, that for example I could tell v4l to use timestamps from an audio clock instead of the system clock.
It's something I don't like. If you have multiple soundcards, it might be problematic to select a proper audio device for sync.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
At Mon, 26 Nov 2007 14:04:47 +0100 (CET), Jaroslav Kysela wrote:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Takashi Iwai kirjoitti:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
The addition of monolithc clock isn't hard, but it's an API change that involves with the kernel-side change. So let's do it carefully.
But, honestly, I'm still concerned what to be done first. Shouldn't we discuss about the usefulness of the timestamp at first? That is, whether the current form (API, implementation) is the best or not, what kind of user would be, and how it's used. So far, this feature is "simply there"...
IMHO the current API definitely isn't the best possible, but nothing better has been available on Linux, so it's a make-do situation. My ideal would be something resembling or even 1:1 copying SGI's media libraries where every media fragment is timestamped with the UST, and the timestamps are the starting time of the media chunk in question instead of ending/sometime after time. The problem with implementing the SGI API on Linux is that AFAICT no Linux supported/available hardware supports such timestamping.
Unfortunately, we are not using audio "packets" at the moment, but basically, it shouldn't be difficult to implement - think one period == one packet.
Yes. About the sync accuracy, this should be fine enough.
Additionally, it might be nice to be able to add audio clocks as system wide clocks, so, that for example I could tell v4l to use timestamps from an audio clock instead of the system clock.
It's something I don't like. If you have multiple soundcards, it might be problematic to select a proper audio device for sync.
But, OTOH, the audio-video-sync is more popular demand than multiple card sync. This might be a good working example for timestamping.
I remember I discussed about it a bit with Mauro. Nnow Cc'ed, in case he has more comments on V4L/sound sync issue.
One possible problem is that the current ALSA timestamp API provides only volatile reads, i.e. the timestamp is being constantly updated and not logged/streamed coupled with the data. That's the reason I suggested to consider the API again. We should check the use case at first...
thanks,
Takashi
On Mon, 26 Nov 2007, Takashi Iwai wrote:
Additionally, it might be nice to be able to add audio clocks as system wide clocks, so, that for example I could tell v4l to use timestamps from an audio clock instead of the system clock.
It's something I don't like. If you have multiple soundcards, it might be problematic to select a proper audio device for sync.
But, OTOH, the audio-video-sync is more popular demand than multiple card sync. This might be a good working example for timestamping.
I remember I discussed about it a bit with Mauro. Nnow Cc'ed, in case he has more comments on V4L/sound sync issue.
One possible problem is that the current ALSA timestamp API provides only volatile reads, i.e. the timestamp is being constantly updated and not logged/streamed coupled with the data.
I'm not sure, if it's a real problem. Applications may handle this internally. The accurate system time might be computed from last sample position (or two last positions or last position and start timestamp) and assigned timestamp from master system clock and sample rate (linear relationship). Of course, it's question, if it will be accurate enough. But it's rather problem with lack of hardware doing timestamping itself than the audio driver subsystem which can only get time as fast as stream position is updated from hardware.
That's the reason I suggested to consider the API again. We should check the use case at first...
Yes, it's good to define goals.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Takashi Iwai kirjoitti:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
The addition of monolithc clock isn't hard, but it's an API change that involves with the kernel-side change. So let's do it carefully.
But, honestly, I'm still concerned what to be done first. Shouldn't we discuss about the usefulness of the timestamp at first? That is, whether the current form (API, implementation) is the best or not, what kind of user would be, and how it's used. So far, this feature is "simply there"...
IMHO the current API definitely isn't the best possible, but nothing better has been available on Linux, so it's a make-do situation. My ideal would be something resembling or even 1:1 copying SGI's media libraries where every media fragment is timestamped with the UST, and the timestamps are the starting time of the media chunk in question instead of ending/sometime after time. The problem with implementing the SGI API on Linux is that AFAICT no Linux supported/available hardware supports such timestamping.
Unfortunately, we are not using audio "packets" at the moment, but basically, it shouldn't be difficult to implement - think one period == one packet.
Exactly what I was thinking. Maybe extend the mmap interface so that timestamps for every period are saved and can be queried. Then create (swipe from v4l2) a packet interface on top of the mmap code. Having the timestamp telling the buffer start time instead of end would be nice, too, and shouldn't be too problematic - periods are small enough, so that a constant offset can be used without causing much theoretical drift. One nice thing about the SGI API is that it works for playback, too. When you send a packet for playback, on return, it fills in the actual playback time. This can/could be much more accurate than the usual get_delay / gettimeofday pair that's used in applications now.
Additionally, it might be nice to be able to add audio clocks as system wide clocks, so, that for example I could tell v4l to use timestamps from an audio clock instead of the system clock.
It's something I don't like. If you have multiple soundcards, it might be problematic to select a proper audio device for sync.
Not to speak of trying to invade outside of sound/ with new clocks.. But that's just an idea.
-- Heikki Lindholm
Takashi Iwai kirjoitti:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
What do you mean by this? Aren't all applications that try to do playback/capture A/V sync or sync between two audio cards or latency measurement potential users? And those kind of apps have definitely been there before 2007-02 (Jaroslav's RFC's date.) If you mean _monotonic_ timestamps, not all users would probably care, though.
-- Heikki Lindholm
At Mon, 26 Nov 2007 12:10:51 +0200, Heikki Lindholm wrote:
Takashi Iwai kirjoitti:
At Mon, 26 Nov 2007 09:59:29 +0200, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I can't seem to google up the proposal. I'd like to read it; was it on the alsa ml?
Yes, it was on alsa-devel ML. At that time I didn't like the proposal much because currently there was no real user of timestamps.
What do you mean by this? Aren't all applications that try to do playback/capture A/V sync or sync between two audio cards or latency measurement potential users? And those kind of apps have definitely been there before 2007-02 (Jaroslav's RFC's date.) If you mean _monotonic_ timestamps, not all users would probably care, though.
I meant as the apps that really use the ALSA timestamp features.
Takashi
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Hello,
Some years ago there was some talk about UST support in Linux, but the support never happened. With the hrtimers patch (and I'm not quite sure if even earlier?) CLOCK_MONOTONIC would seem like a fairly good UST time source. What I'd like to see, is a selectable clock for ALSA timestamping, e.g. something like snd_sw_params_clock(..., clockid_t clk). Would this seem plausible? I don't know that much about ALSA internals, so, no idea whether different clocks on different pcms/whatever would quickly turn into an unmanageable mess.
We are aware about this extension and I already proposed an implementation. I hope to implement it soon. Timestamps are not used in driver internally.
I had a look at the proposal and the thread at http://thread.gmane.org/gmane.linux.alsa.devel/45237/focus=45573 I don't know about the history of SNDRV_PCM_IOCTL_TSTAMP, but since it currently seems unused I don't see a problem reusing it for something (else). However, I think that it'd be nicer to define the API to use a POSIX clock id instead of some arbitrary constants, because there have been/are other clocks on Linux, for example, CLOCK_SGI_CYCLE. An update to pcm_status might also be in order to tell which clock is being used.
-- Heikki Lindholm
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
I had a look at the proposal and the thread at http://thread.gmane.org/gmane.linux.alsa.devel/45237/focus=45573
My initial implementation following proposal is bellow for review and comments. I also changed timestamps for ALSA timers to use monotonic clocks (can be switched back using a module parameter).
Jaroslav
diff -r 5e8cab953031 core/pcm_lib.c --- a/core/pcm_lib.c Mon Nov 26 09:00:56 2007 +0100 +++ b/core/pcm_lib.c Mon Nov 26 14:50:01 2007 +0100 @@ -188,7 +188,7 @@ static inline int snd_pcm_update_hw_ptr_ snd_pcm_sframes_t delta;
if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_MMAP) - getnstimeofday((struct timespec *)&runtime->status->tstamp); + snd_pcm_gettime(runtime, (struct timespec *)&runtime->status->tstamp); pos = snd_pcm_update_hw_ptr_pos(substream, runtime); if (pos == SNDRV_PCM_POS_XRUN) { xrun(substream); diff -r 5e8cab953031 core/pcm_native.c --- a/core/pcm_native.c Mon Nov 26 09:00:56 2007 +0100 +++ b/core/pcm_native.c Mon Nov 26 15:19:22 2007 +0100 @@ -598,9 +598,9 @@ int snd_pcm_status(struct snd_pcm_substr if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_MMAP) status->tstamp = runtime->status->tstamp; else - getnstimeofday(&status->tstamp); + snd_pcm_gettime(runtime, &status->tstamp); } else - getnstimeofday(&status->tstamp); + snd_pcm_gettime(runtime, &status->tstamp); status->appl_ptr = runtime->control->appl_ptr; status->hw_ptr = runtime->status->hw_ptr; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { @@ -688,7 +688,7 @@ static void snd_pcm_trigger_tstamp(struc if (runtime->trigger_master == NULL) return; if (runtime->trigger_master == substream) { - getnstimeofday(&runtime->trigger_tstamp); + snd_pcm_gettime(runtime, &runtime->trigger_tstamp); } else { snd_pcm_trigger_tstamp(runtime->trigger_master); runtime->trigger_tstamp = runtime->trigger_master->runtime->trigger_tstamp; @@ -2519,6 +2519,21 @@ static int snd_pcm_sync_ptr(struct snd_p return -EFAULT; return 0; } + +static int snd_pcm_tstamp(struct snd_pcm_substream *substream, int __user *_arg) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + int arg; + + if (get_user(arg, _arg)) + return -EFAULT; + if (arg < 0 || arg > SNDRV_PCM_TSTAMP_TYPE_LAST) + return -EINVAL; + runtime->tstamp_type = SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY; + if (arg == SNDRV_PCM_TSTAMP_TYPE_MONOTONIC) + runtime->tstamp_type = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC; + return 0; +} static int snd_pcm_common_ioctl1(struct file *file, struct snd_pcm_substream *substream, @@ -2531,8 +2546,8 @@ static int snd_pcm_common_ioctl1(struct return put_user(SNDRV_PCM_VERSION, (int __user *)arg) ? -EFAULT : 0; case SNDRV_PCM_IOCTL_INFO: return snd_pcm_info_user(substream, arg); - case SNDRV_PCM_IOCTL_TSTAMP: /* just for compatibility */ - return 0; + case SNDRV_PCM_IOCTL_TSTAMP: + return snd_pcm_tstamp(substream, arg); case SNDRV_PCM_IOCTL_HW_REFINE: return snd_pcm_hw_refine_user(substream, arg); case SNDRV_PCM_IOCTL_HW_PARAMS: diff -r 5e8cab953031 core/timer.c --- a/core/timer.c Mon Nov 26 09:00:56 2007 +0100 +++ b/core/timer.c Mon Nov 26 14:59:33 2007 +0100 @@ -44,11 +44,14 @@ #endif
static int timer_limit = DEFAULT_TIMER_LIMIT; +static int timer_tstamp_monotonic = 1; MODULE_AUTHOR("Jaroslav Kysela perex@perex.cz, Takashi Iwai tiwai@suse.de"); MODULE_DESCRIPTION("ALSA timer interface"); MODULE_LICENSE("GPL"); module_param(timer_limit, int, 0444); MODULE_PARM_DESC(timer_limit, "Maximum global timers in system."); +module_param(timer_tstamp_monotonic, int, 0444); +MODULE_PARM_DESC(timer_tstamp_monotonic, "Use posix monotonic clock source for timestamps (default).");
struct snd_timer_user { struct snd_timer_instance *timeri; @@ -381,7 +384,10 @@ static void snd_timer_notify1(struct snd struct snd_timer_instance *ts; struct timespec tstamp;
- getnstimeofday(&tstamp); + if (timer_tstamp_monotonic) + do_posix_clock_monotonic_gettime(&tstamp); + else + getnstimeofday(&tstamp); snd_assert(event >= SNDRV_TIMER_EVENT_START && event <= SNDRV_TIMER_EVENT_PAUSE, return); if (event == SNDRV_TIMER_EVENT_START || @@ -1182,8 +1188,12 @@ static void snd_timer_user_tinterrupt(st spin_unlock(&tu->qlock); return; } - if (tu->last_resolution != resolution || ticks > 0) - getnstimeofday(&tstamp); + if (tu->last_resolution != resolution || ticks > 0) { + if (timer_tstamp_monotonic) + do_posix_clock_monotonic_gettime(&tstamp); + else + getnstimeofday(&tstamp); + } if ((tu->filter & (1 << SNDRV_TIMER_EVENT_RESOLUTION)) && tu->last_resolution != resolution) { r1.event = SNDRV_TIMER_EVENT_RESOLUTION; diff -r 5e8cab953031 include/asound.h --- a/include/asound.h Mon Nov 26 09:00:56 2007 +0100 +++ b/include/asound.h Mon Nov 26 15:02:57 2007 +0100 @@ -435,6 +435,13 @@ struct snd_xfern { };
enum { + SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY = 0, /* gettimeofday equivalent */ + SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY1, /* for compatibility, equal to zero */ + SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, /* posix_clock_monotonic equivalent */ + SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, +}; + +enum { SNDRV_PCM_IOCTL_PVERSION = _IOR('A', 0x00, int), SNDRV_PCM_IOCTL_INFO = _IOR('A', 0x01, struct snd_pcm_info), SNDRV_PCM_IOCTL_TSTAMP = _IOW('A', 0x02, int), diff -r 5e8cab953031 include/pcm.h --- a/include/pcm.h Mon Nov 26 09:00:56 2007 +0100 +++ b/include/pcm.h Mon Nov 26 15:20:22 2007 +0100 @@ -323,6 +323,7 @@ struct snd_pcm_runtime {
/* -- timer -- */ unsigned int timer_resolution; /* timer resolution */ + int tstamp_type; /* timestamp type */
/* -- DMA -- */ unsigned char *dma_area; /* DMA area */ @@ -952,6 +953,15 @@ void snd_pcm_timer_init(struct snd_pcm_s void snd_pcm_timer_init(struct snd_pcm_substream *substream); void snd_pcm_timer_done(struct snd_pcm_substream *substream);
+static inline void snd_pcm_gettime(struct snd_pcm_runtime *runtime, + struct timespec *tv) +{ + if (runtime->tstamp_type == SNDRV_PCM_TSTAMP_TYPE_MONOTONIC) + do_posix_clock_monotonic_gettime(tv); + else + getnstimeofday(tv); +} + /* * Memory */
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
I had a look at the proposal and the thread at http://thread.gmane.org/gmane.linux.alsa.devel/45237/focus=45573
My initial implementation following proposal is bellow for review and comments. I also changed timestamps for ALSA timers to use monotonic clocks (can be switched back using a module parameter).
Jaroslavdiff -r 5e8cab953031 core/pcm_lib.c --- a/core/pcm_lib.c Mon Nov 26 09:00:56 2007 +0100
<...>
diff -r 5e8cab953031 include/asound.h --- a/include/asound.h Mon Nov 26 09:00:56 2007 +0100 +++ b/include/asound.h Mon Nov 26 15:02:57 2007 +0100 @@ -435,6 +435,13 @@ struct snd_xfern { };
enum {
- SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY = 0, /* gettimeofday equivalent */
- SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY1, /* for compatibility, equal to zero */
- SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, /* posix_clock_monotonic equivalent */
- SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC,
+};
Looks good otherwise, but I'd still like to argue about this compatibility point: compatibility with what exactly? When was PCM_TSTAMP ioctl deprecated? Before 1.0.0? Has anyone *ever* used it? And so, is there any point in adding something not-so-pretty to a new feature right from the start. Just declare legacy TSTAMP ioctl users scr*wed! :)
The good thing is that this change has, AFAICS, nothing contradicting with redesigning the timestamp API, so that could be left open and this stuff still applied.
-- Heikki Lindholm
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
Jaroslav Kysela kirjoitti:
On Mon, 26 Nov 2007, Heikki Lindholm wrote:
I had a look at the proposal and the thread at http://thread.gmane.org/gmane.linux.alsa.devel/45237/focus=45573
My initial implementation following proposal is bellow for review and comments. I also changed timestamps for ALSA timers to use monotonic clocks (can be switched back using a module parameter).
Jaroslav
diff -r 5e8cab953031 core/pcm_lib.c --- a/core/pcm_lib.c Mon Nov 26 09:00:56 2007 +0100
<...>
diff -r 5e8cab953031 include/asound.h --- a/include/asound.h Mon Nov 26 09:00:56 2007 +0100 +++ b/include/asound.h Mon Nov 26 15:02:57 2007 +0100 @@ -435,6 +435,13 @@ struct snd_xfern { };
enum {
- SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY = 0, /* gettimeofday equivalent */
- SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY1, /* for compatibility, equal to
zero */
- SNDRV_PCM_TSTAMP_TYPE_MONOTONIC, /* posix_clock_monotonic
equivalent */
- SNDRV_PCM_TSTAMP_TYPE_LAST = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC,
+};
Looks good otherwise, but I'd still like to argue about this compatibility point: compatibility with what exactly? When was PCM_TSTAMP ioctl deprecated? Before 1.0.0? Has anyone *ever* used it?
Looking at sources, we talking about a 0.9.0rc8 change.
And so, is there any point in adding something not-so-pretty to a new feature right from the start. Just declare legacy TSTAMP ioctl users scr*wed! :)
This ioctl is used only by alsa-lib and the post 0.9.0rc8 code checks for PCM API version, so we should not have any problem except with the binary compatibility with 0.9.0rc libraries.
Ok, I'll remove GETTIMEOFDAY1 and commit code to HG tree.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
participants (3)
-
Heikki Lindholm -
Jaroslav Kysela -
Takashi Iwai