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

[Tanu Kaskinen]

On Mon, May 18, 2015, at 21:56, Sébastien Barthélémy wrote:
> Hello,
> 
> I'm looking at how our pulseaudio client behaves if the CLOCK_REALTIME is
> changed.
> 
> 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
> ==
> FALSE.
> 
> My guess is that, in the test a bit above ([2]). we have
> command==PA_COMMAND_TIMEOUT.
> 
> Is there any way to test that hypothesis?

The callback given to pa_stream_update_timing_info() has type
pa_context_success_cb_t, which has the "success" argument. If "success"
is false, you can get the error code with pa_context_errno(). If the
operation failed due to a timeout, the error code should be
PA_ERR_TIMEOUT.

> 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,

You're probably correct, but I can't confirm without digging deeper in
the code.

> 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?

No, you didn't miss anything. pa_context seems to only support this for
pa_mainloop.

> 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?

I don't know (or remember) the reason. I would guess that it has to do
with maintaining a stable public API and avoiding unnecessary complexity
in the API. However, if there's need for enabling the rtclock stuff for
custom mainloops, I'd expect there to be some way to implement that
without breaking backwards compatibility.

-- 
Tanu