[pulseaudio-discuss] precise stream timing

[Matt Robbins]

Thanks for your input Colin,  I think you understand correctly, but it
doesn't look like pa_stream_get_time() is really going to do it for me.  I
did find a way to get something close to what I want, however.  If it turn
on PA_STREAM_AUTO_TIMING_UPDATE without PA_STREAM_INTERPOLATE_TIMING, then
the time stamp returned by pa_stream_get_time() (or equivalently
pa_stream_get_timing_info()) increases in a step-wise fashion.  This is
fine, because I can estimate the time for the in-between step callbacks
using the number of bytes read, and pa_bytes_to_usec().

In fact, it seems like this estimate is quite precise.  Looking at the value
of gettimeofday() on two separate clients when when the time stamp steps
forward, they are nearly equal (within 500 usec), and I verified that the
data recorded for that invocation of the callback is equal for both clients.
  This looks really promising to me, but with more than two clients, the
time difference starts to add up, and I wind up with unacceptably differing
time estimates.

It seems like I ought to be able to use pa_timing_info to refine my
estimate, accounting for the varying per-client delay, but I can't seem to
make sense of the other values in the pa_timing_info struct.  The timestamp
itself is not even close between clients (off by 1/3rd of a second or more
and fluctuating), and pa_source_usec, though it fluctuates as well, doesn't
account for the difference an any way that's more accurate than my
gettimeofday() method.   Transport_usec seems to always be around 100us
regardless, so it doesn't account for the timing difference between clients
either.  Basically, I can't  do better than calling gettimofday() when the
"time stamp step" occurs.  Can I count on this behavior?

The frustrating thing is that pulse seems to be capable of sub-millisecond
timing (as evidenced by the close temporal proximity of callbacks in two
separate clients), but nothing in the API can give me what I want.  I really
don't want to give up since pulse provides so many other fantastic features,
and is supported in many distributions by default.   I'm thinking that I
might be interested in working on the back end code that involves record
stream timing.  Would you be able to point me to a starting place?

Thanks,
Matt

On Thu, Jun 2, 2011 at 10:51 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:

> 'Twas brillig, and Matt Robbins at 02/06/11 16:33 did gyre and gimble:
> > Hello Pulseaudio community,
> >
> > I'm playing around with pulse to assess suitability for my project, and
> > while it seems like I should be able to do what I want, I'm struggling
> > with the API.  Essentially, I need to record audio data with precise
> > (~1ms) time stamps.  I'm doing collaborative sound source localization
> > between several machines, all synced to gps time.  Since I don't really
> > need sample-accurate time, I figured it would be acceptable to call
> > gettimeofday() on ALSA interrupts to get a pretty good idea of when the
> > samples were recorded.  Since all of the machines will be using the same
> > hardware, I don't even care if there's some fixed latency involved.
> >  While doing this in ALSA would be an interesting project, when combined
> > with some the other things I need to do (stream splitting, fixed-point
> > resampling, etc.), it feels like I'd be reinventing the wheel.  I've
> > been using JACK to accomplish what I need, but there are stability and
> > support issues on the embedded systems I'm using, so I'm looking into
> > alternatives, especially since the recent headless ubuntu release, which
> > has a working pulse server by default :)
> >
> > I've tried cobbling something together using the pacat.c source using
> > pa_stream_set_read_callback().  My callback gets called, but although I
> > call pa_stream_get_timing_info(), I can't see how to derive the
> > information I need from the pa_timing_info struct because I can't see
> > how the timestamp field is related to the current fragment.
> >
> > I'm not even sure if I'm going about this the right way, so if anyone
> > who knows the system could give me a few pointers, I'd really appreciate
> it.
>
> I suspect you want to use:
> pa_stream_get_time().
>
> This returns the usecs since the stream started... this is likely what
> you want (IIUC).
>
> Cheers
>
> Col
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mageia Contributor [http://www.mageia.org/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110607/56735ee4/attachment-0001.htm>