All of lore.kernel.org
 help / color / mirror / Atom feed
* Timing Info
@ 2010-06-11 22:00 Paul Dugas
  2010-06-12 21:59 ` Paul Dugas
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Dugas @ 2010-06-11 22:00 UTC (permalink / raw)
  To: alsa-devel

I'm using snd_pcm_readi() to collect samples and am wondering if/how I
can get accurate timestamps for them.  Seems like the snd_pcm_status()
gives me this info but I'm unclear on the specifics.  Can someone
point me toward the correct field in the status structure that I
should be using and what sample that timestamp corresponds to?

Does snd_pcm_status_get_tstamp() get me the timestamp for the first
frame returned by the next snd_pcm_readi() call?


P

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Timing Info
  2010-06-11 22:00 Timing Info Paul Dugas
@ 2010-06-12 21:59 ` Paul Dugas
  2010-06-13 14:10   ` Clemens Ladisch
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Dugas @ 2010-06-12 21:59 UTC (permalink / raw)
  To: alsa-devel

On Fri, Jun 11, 2010 at 6:00 PM, Paul Dugas <paul@dugasenterprises.com> wrote:
> I'm using snd_pcm_readi() to collect samples and am wondering if/how I
> can get accurate timestamps for them.  Seems like the snd_pcm_status()
> gives me this info but I'm unclear on the specifics.  Can someone
> point me toward the correct field in the status structure that I
> should be using and what sample that timestamp corresponds to?
>
> Does snd_pcm_status_get_tstamp() get me the timestamp for the first
> frame returned by the next snd_pcm_readi() call?

I know now get_tstamp() isn't what I'm looking for after reading some
prior postings and other web sites.  Can't seem to find a discussion
of timing in the ALSA docs themselves.  Maybe I'm being dense.

Looks like some processing of the trigger timestamp is what I need but
I'm not following the logic of "triggers" in the simple use of
snd_pcm_readi() that I've got.  Before the first readi() call, the
trigger time is 0.  The second time, it's pretty close to the wall
time for the first call.  Perhaps that's the timestamp of the first
sample of the first period I read and I need to add the period_time
each time?  Seems like that'd accrue error when recording over longer
periods of time (which my application does).

What's the "timestamp mode".  Does it generate a timestamp each
period?  How would I access that timestamp?

Thanks in advance for any assistance,

Paul
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Timing Info
  2010-06-12 21:59 ` Paul Dugas
@ 2010-06-13 14:10   ` Clemens Ladisch
  2010-06-13 19:47     ` Paul Dugas
  2010-06-15 17:00     ` Paul Dugas
  0 siblings, 2 replies; 7+ messages in thread
From: Clemens Ladisch @ 2010-06-13 14:10 UTC (permalink / raw)
  To: Paul Dugas; +Cc: alsa-devel

Paul Dugas wrote:
> Looks like some processing of the trigger timestamp is what I need

Trigger events are starting or stopping of a stream.

> What's the "timestamp mode".  Does it generate a timestamp each
> period?  How would I access that timestamp?

Set SND_PCM_TSTAMP_ENABLE to generate a timestamp whenever the hardware
position is updated.  Call snd_pcm_status to read the position and the
corresponding timestamp.


HTH
Clemens

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Timing Info
  2010-06-13 14:10   ` Clemens Ladisch
@ 2010-06-13 19:47     ` Paul Dugas
  2010-06-14 22:54       ` Paul Dugas
  2010-06-15 17:00     ` Paul Dugas
  1 sibling, 1 reply; 7+ messages in thread
From: Paul Dugas @ 2010-06-13 19:47 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: alsa-devel

On Sun, Jun 13, 2010 at 10:10 AM, Clemens Ladisch <clemens@ladisch.de>wrote:

> Paul Dugas wrote:
> > What's the "timestamp mode".  Does it generate a timestamp each
> > period?  How would I access that timestamp?
>
> Set SND_PCM_TSTAMP_ENABLE to generate a timestamp whenever the hardware
> position is updated.  Call snd_pcm_status to read the position and the
> corresponding timestamp.
>

So, does setting SND_PCM_TSTAMP_ENABLE change the meaning of the tstamp
field in the status?  I believe I read somewhere that with TSTAMP_NONE,
tstamp was set to "now" when readi() was called.  Does it change to meaning
" the timestamp od the first frame returned"?  If not, where do I look?

Much thanks,

Paul

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Timing Info
  2010-06-13 19:47     ` Paul Dugas
@ 2010-06-14 22:54       ` Paul Dugas
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Dugas @ 2010-06-14 22:54 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: alsa-devel

On Sun, Jun 13, 2010 at 3:47 PM, Paul Dugas <paul@dugasenterprises.com> wrote:
> On Sun, Jun 13, 2010 at 10:10 AM, Clemens Ladisch <clemens@ladisch.de>
> wrote:
>>
>> Paul Dugas wrote:
>> > What's the "timestamp mode".  Does it generate a timestamp each
>> > period?  How would I access that timestamp?
>>
>> Set SND_PCM_TSTAMP_ENABLE to generate a timestamp whenever the hardware
>> position is updated.  Call snd_pcm_status to read the position and the
>> corresponding timestamp.
>
> So, does setting SND_PCM_TSTAMP_ENABLE change the meaning of the tstamp
> field in the status?  I believe I read somewhere that with TSTAMP_NONE,
> tstamp was set to "now" when readi() was called.  Does it change to meaning
> " the timestamp od the first frame returned"?  If not, where do I look?

I spun up a test program but I'm not seeing what I expect.  I'm still
missing something.

I'm calling snd_pcm_status() and snd_pcm_status_dump() before each
snd_pcm_readi() call.  I see the "trigger_time" not changing (after
the first readi call).  The "tsamp" isn't increasing in consistent
steps.  I expect it to be consistently 10,666 usecs per the
"period_time" value below.

The PCM device is configured like so:
  >  Plug PCM: Linear Integer <-> Linear Float conversion PCM (S32_LE)
  >  Its setup is:
  >    stream       : CAPTURE
  >    access       : RW_INTERLEAVED
  >    format       : FLOAT64_LE
  >    subformat    : STD
  >    channels     : 8
  >    rate         : 96000
  >    exact rate   : 96000 (96000/1)
  >    msbits       : 64
  >    buffer_size  : 32768
  >    period_size  : 1024
  >    period_time  : 10666
  >    tstamp_mode  : ENABLE
  >    period_step  : 1
  >    avail_min    : 1024
  >    period_event : 0
  >    start_threshold  : 1
  >    stop_threshold   : 32768
  >    silence_threshold: 0
  >    silence_size : 0
  >    boundary     : 4611686018427387904
  >  Slave: Route conversion PCM (sformat=S32_LE)
  >    Transformation table:
  >      0 <- 0
  >      1 <- 1
  >      2 <- none
  >      3 <- none
  >      4 <- none
  >      5 <- none
  >      6 <- none
  >      7 <- none
  >  Its setup is:
  >    stream       : CAPTURE
  >    access       : MMAP_INTERLEAVED
  >    format       : S32_LE
  >    subformat    : STD
  >    channels     : 8
  >    rate         : 96000
  >    exact rate   : 96000 (96000/1)
  >    msbits       : 32
  >    buffer_size  : 32768
  >    period_size  : 1024
  >    period_time  : 10666
  >    tstamp_mode  : ENABLE
  >    period_step  : 1
  >    avail_min    : 1024
  >    period_event : 0
  >    start_threshold  : 1
  >    stop_threshold   : 32768
  >    silence_threshold: 0
  >    silence_size : 0
  >    boundary     : 4611686018427387904
  >  Slave: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0
  >  Its setup is:
  >    stream       : CAPTURE
  >    access       : MMAP_INTERLEAVED
  >    format       : S32_LE
  >    subformat    : STD
  >    channels     : 2
  >    rate         : 96000
  >    exact rate   : 96000 (96000/1)
  >    msbits       : 32
  >    buffer_size  : 32768
  >    period_size  : 1024
  >    period_time  : 10666
  >    tstamp_mode  : ENABLE
  >    period_step  : 1
  >    avail_min    : 1024
  >    period_event : 0
  >    start_threshold  : 1
  >    stop_threshold   : 32768
  >    silence_threshold: 0
  >    silence_size : 0
  >    boundary     : 4611686018427387904
  >    appl_ptr     : 0
  >    hw_ptr       : 0

Hmmm....   Not sure what to try next.

Paul
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Timing Info
  2010-06-13 14:10   ` Clemens Ladisch
  2010-06-13 19:47     ` Paul Dugas
@ 2010-06-15 17:00     ` Paul Dugas
  2010-06-17 15:36       ` Clemens Ladisch
  1 sibling, 1 reply; 7+ messages in thread
From: Paul Dugas @ 2010-06-15 17:00 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: alsa-devel

On Sun, Jun 13, 2010 at 10:10 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Set SND_PCM_TSTAMP_ENABLE to generate a timestamp whenever the hardware
> position is updated.  Call snd_pcm_status to read the position and the
> corresponding timestamp.

I've re-read this a number of times and have been fiddling with code
that dumps the status at various points but I'm still not grasping the
concept here.  Can comeone point me to an explanation of the delay,
avail, and avail_max values?  Maybe I can figure this out with that.

Paul

PS: Is there a better place to ask questions like these?  People on
#alsa at Freenode sent me here.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Timing Info
  2010-06-15 17:00     ` Paul Dugas
@ 2010-06-17 15:36       ` Clemens Ladisch
  0 siblings, 0 replies; 7+ messages in thread
From: Clemens Ladisch @ 2010-06-17 15:36 UTC (permalink / raw)
  To: Paul Dugas; +Cc: alsa-devel

Paul Dugas wrote:
> On Sun, Jun 13, 2010 at 10:10 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > Set SND_PCM_TSTAMP_ENABLE to generate a timestamp whenever the hardware
> > position is updated.  Call snd_pcm_status to read the position and the
> > corresponding timestamp.
> 
> I've re-read this a number of times and have been fiddling with code
> that dumps the status at various points but I'm still not grasping the
> concept here.  Can comeone point me to an explanation of the delay,
> avail, and avail_max values?

The avail value tells you how many frames are available, i.e., can be
written, in the output buffer.  The largest value that this had since
the last snd_pcm_status call is avail_max.

The delay value is the time that will elapse before the next frame that
you write into the buffer will actually be output by the hardware.  This
is not only the time until the hardware reads this frame out of the
buffer (which could be computed from avail) but also any processing
after that.


HTH
Clemens

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-06-17 15:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-11 22:00 Timing Info Paul Dugas
2010-06-12 21:59 ` Paul Dugas
2010-06-13 14:10   ` Clemens Ladisch
2010-06-13 19:47     ` Paul Dugas
2010-06-14 22:54       ` Paul Dugas
2010-06-15 17:00     ` Paul Dugas
2010-06-17 15:36       ` Clemens Ladisch

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.