[pulseaudio-discuss] making a custom mainloop robust to clock changes
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 ) with o->stream->timing_info_valid ==
My guess is that, in the test a bit above (). 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  (and not just a the timeout duration), which is then (see
pa_timeval_rtstore ) 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 , back in 2009 ) 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...
More information about the pulseaudio-discuss