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>
