[pulseaudio-discuss] making a custom mainloop robust to clock changes

Sébastien Barthélémy barthelemy at crans.org
Mon May 18 11:56:42 PDT 2015


I'm looking at how our pulseaudio client behaves if the CLOCK_REALTIME is

So I'm changing set the clock randomly every second and watching the result.

In some cases our application fails to get the stream latency: our
callback, which was set using pa_stream_update_timing_info(), is called (in
stream_get_timing_info_callback  [1]) with o->stream->timing_info_valid ==

My guess is that, in the test a bit above ([2]). we have

Is there any way to test that hypothesis?

It seems indeed that one sets a callback timeout using a pa_rtclock time
point [3] (and not just a the timeout duration), which is then (see
pa_timeval_rtstore [4]) converted to a CLOCK_REALTIME time point.

I expect that pa_rtclock uses CLOCK_MONOTONIC internally, but converting it
to CLOCK_REALTIME makes the timeout mechanism vulnerable to clock changes.

There is apparently some mechanism (enabled at [5], back in 2009 [6]) to
use pa_rtclock time points for the timeout, but if found no way to enable
it for our custom mainloop. Did I miss something?

Moreover, it involves setting some magical bit in the timeval to indicate
this is a "rtclock" one. Does someone recall the reason for this trick, as
opposed to, say, a (simpler) boolean option when setting up the mainloop?
(The question may be stupid, sorry, this is my first foray in pulseaudio).







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150518/cf40560e/attachment.html>

More information about the pulseaudio-discuss mailing list