RFC: Add support for monotonic clock for 2.6

RFC: Add support for monotonic clock for 2.6

[Jaroslav Kysela]

Hi,

	in 2.6 kernels, we can use ktime_get_ts() function to get 
monotonic time which can be used for PCM timestamps. I would propose to 
reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to enable using of monotonic clock.
The "enable" (int) argument might mean:

0: standard clock - getnstimeofday()
1: standard clock - getnstimeofday() - for "compatibility"
2: monotonic clock - ktime_get_ts()

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RFC: Add support for monotonic clock for 2.6

[Takashi Iwai]

At Tue, 27 Feb 2007 15:52:41 +0100 (CET),
Jaroslav Kysela wrote:
> 
> Hi,
> 
> 	in 2.6 kernels, we can use ktime_get_ts() function to get 
> monotonic time which can be used for PCM timestamps. I would propose to 
> reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to enable using of monotonic clock.
> The "enable" (int) argument might mean:
> 
> 0: standard clock - getnstimeofday()
> 1: standard clock - getnstimeofday() - for "compatibility"
> 2: monotonic clock - ktime_get_ts()

Good to add a new feature...  but is there any user of this PCM
timestamp so far?  I see some good purposes but rarely seen in the
reality, unfortunately...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RFC: Add support for monotonic clock for 2.6

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Tue, 27 Feb 2007 15:52:41 +0100 (CET),
> Jaroslav Kysela wrote:
>> Hi,
>>
>> 	in 2.6 kernels, we can use ktime_get_ts() function to get 
>> monotonic time which can be used for PCM timestamps. I would propose to 
>> reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to enable using of monotonic clock.
>> The "enable" (int) argument might mean:
>>
>> 0: standard clock - getnstimeofday()
>> 1: standard clock - getnstimeofday() - for "compatibility"
>> 2: monotonic clock - ktime_get_ts()
> 
> Good to add a new feature...  but is there any user of this PCM
> timestamp so far?  I see some good purposes but rarely seen in the
> reality, unfortunately...
> 
> 
> Takashi
> 

There are some good applications for it, but I have not got round to 
writing them yet!

James




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RFC: Add support for monotonic clock for 2.6

[Takashi Iwai]

At Wed, 07 Mar 2007 22:33:25 +0000,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 27 Feb 2007 15:52:41 +0100 (CET),
> > Jaroslav Kysela wrote:
> >> Hi,
> >>
> >> 	in 2.6 kernels, we can use ktime_get_ts() function to get 
> >> monotonic time which can be used for PCM timestamps. I would propose to 
> >> reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to enable using of monotonic clock.
> >> The "enable" (int) argument might mean:
> >>
> >> 0: standard clock - getnstimeofday()
> >> 1: standard clock - getnstimeofday() - for "compatibility"
> >> 2: monotonic clock - ktime_get_ts()
> > 
> > Good to add a new feature...  but is there any user of this PCM
> > timestamp so far?  I see some good purposes but rarely seen in the
> > reality, unfortunately...
> > 
> > 
> > Takashi
> > 
> 
> There are some good applications for it, but I have not got round to 
> writing them yet!

Me too ;)  But, I remember some difficulties regarding the
timestamping at the last time I tried (quite ago).  The timestamp is
somewhat hard to use because it's updated at each pointer or status
update although I wanted to get the exact time only at the period
boundary.  Maybe these usability issues should be sorted out all
together.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RFC: Add support for monotonic clock for 2.6

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Wed, 07 Mar 2007 22:33:25 +0000,
> James Courtier-Dutton wrote:
>> Takashi Iwai wrote:
>>> At Tue, 27 Feb 2007 15:52:41 +0100 (CET),
>>> Jaroslav Kysela wrote:
>>>> Hi,
>>>>
>>>> 	in 2.6 kernels, we can use ktime_get_ts() function to get 
>>>> monotonic time which can be used for PCM timestamps. I would propose to 
>>>> reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to enable using of monotonic clock.
>>>> The "enable" (int) argument might mean:
>>>>
>>>> 0: standard clock - getnstimeofday()
>>>> 1: standard clock - getnstimeofday() - for "compatibility"
>>>> 2: monotonic clock - ktime_get_ts()
>>> Good to add a new feature...  but is there any user of this PCM
>>> timestamp so far?  I see some good purposes but rarely seen in the
>>> reality, unfortunately...
>>>
>>>
>>> Takashi
>>>
>> There are some good applications for it, but I have not got round to 
>> writing them yet!
> 
> Me too ;)  But, I remember some difficulties regarding the
> timestamping at the last time I tried (quite ago).  The timestamp is
> somewhat hard to use because it's updated at each pointer or status
> update although I wanted to get the exact time only at the period
> boundary.  Maybe these usability issues should be sorted out all
> together.
> 
> 
> Takashi

Yes, timestamp at period boundary would be more useful. I had not looked 
at the current timestamp in enough details. A timestamp generated in the 
IRQ routine would probably be the best. Could the timestamp be attached 
to a particular PCM sample in the buffer. I.e. The app would retrieve 
the timestamp, and be told that that timestamp applies to the sample X 
samples from now, if using the snd_pcm_read() function.

James


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RFC: Add support for monotonic clock for 2.6

[Jaroslav Kysela]

On Wed, 7 Mar 2007, James Courtier-Dutton wrote:

> Takashi Iwai wrote:
> > At Tue, 27 Feb 2007 15:52:41 +0100 (CET),
> > Jaroslav Kysela wrote:
> > > Hi,
> > > 
> > > 	in 2.6 kernels, we can use ktime_get_ts() function to get
> > > monotonic time which can be used for PCM timestamps. I would propose
> > > to reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to enable using of
> > > monotonic clock.
> > > The "enable" (int) argument might mean:
> > > 
> > > 0: standard clock - getnstimeofday()
> > > 1: standard clock - getnstimeofday() - for "compatibility"
> > > 2: monotonic clock - ktime_get_ts()
> > 
> > Good to add a new feature...  but is there any user of this PCM
> > timestamp so far?  I see some good purposes but rarely seen in the
> > reality, unfortunately...
> > 
> > 
> > Takashi
> > 
> 
> There are some good applications for it, but I have not got round to writing
> them yet!

I'd like to use these timestamps to do jitter (sample rate) corrections 
among multiple soundcards. Unfortunately, because gettimeofday is not 
monotonic, the timestamps are not accurate enough. Also, direct plugins 
might use these timestamps to do more accurate stream start.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RFC: Add support for monotonic clock for 2.6

[Jaroslav Kysela]

On Wed, 7 Mar 2007, James Courtier-Dutton wrote:

> Takashi Iwai wrote:
> > At Wed, 07 Mar 2007 22:33:25 +0000,
> > James Courtier-Dutton wrote:
> > > Takashi Iwai wrote:
> > > > At Tue, 27 Feb 2007 15:52:41 +0100 (CET),
> > > > Jaroslav Kysela wrote:
> > > > > Hi,
> > > > > 
> > > > > 	in 2.6 kernels, we can use ktime_get_ts() function to
> > > > > get monotonic time which can be used for PCM timestamps. I
> > > > > would propose to reuse the SNDRV_PCM_IOCTL_TSTAMP ioctl to
> > > > > enable using of monotonic clock.
> > > > > The "enable" (int) argument might mean:
> > > > > 
> > > > > 0: standard clock - getnstimeofday()
> > > > > 1: standard clock - getnstimeofday() - for "compatibility"
> > > > > 2: monotonic clock - ktime_get_ts()
> > > > Good to add a new feature...  but is there any user of this PCM
> > > > timestamp so far?  I see some good purposes but rarely seen in
> > > > the
> > > > reality, unfortunately...
> > > > 
> > > > 
> > > > Takashi
> > > > 
> > > There are some good applications for it, but I have not got round to
> > > writing them yet!
> > 
> > Me too ;)  But, I remember some difficulties regarding the
> > timestamping at the last time I tried (quite ago).  The timestamp is
> > somewhat hard to use because it's updated at each pointer or status
> > update although I wanted to get the exact time only at the period
> > boundary.  Maybe these usability issues should be sorted out all
> > together.
> > 
> > 
> > Takashi
> 
> Yes, timestamp at period boundary would be more useful. I had not looked at
> the current timestamp in enough details. A timestamp generated in the IRQ
> routine would probably be the best. Could the timestamp be attached to a
> particular PCM sample in the buffer. I.e. The app would retrieve the
> timestamp, and be told that that timestamp applies to the sample X samples
> from now, if using the snd_pcm_read() function.

If SNDRV_PCM_TSTAMP_MMAP is set 
(snd_pcm_sw_params_set_tstamp_mode(SND_PCM_TSTAMP_MMAP)) , the timestamp 
is updated at each change of hw_ptr in driver (thus also in the interrupt 
handler).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV