POSIX clocks and ALSA

POSIX clocks and ALSA

[Heikki Lindholm]

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

Re: POSIX clocks and ALSA

[Jaroslav Kysela]

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

Re: POSIX clocks and ALSA

[Heikki Lindholm]

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

Re: POSIX clocks and ALSA

[Takashi Iwai]

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

Re: POSIX clocks and ALSA

[Jaroslav Kysela]

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

Re: POSIX clocks and ALSA

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

Re: POSIX clocks and ALSA

[Heikki Lindholm]

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

Re: POSIX clocks and ALSA

[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

Re: POSIX clocks and ALSA

[Takashi Iwai]

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

Re: POSIX clocks and ALSA

[Jaroslav Kysela]

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

Re: POSIX clocks and ALSA

[Takashi Iwai]

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

Re: POSIX clocks and ALSA

[Jaroslav Kysela]

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

Re: POSIX clocks and ALSA

[Jaroslav Kysela]

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

Re: POSIX clocks and ALSA

[Heikki Lindholm]

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? 
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

Re: POSIX clocks and ALSA

[Heikki Lindholm]

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

Re: POSIX clocks and ALSA

[Jaroslav Kysela]

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