<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 22, 2015 at 1:45 PM, Tanu Kaskinen <span dir="ltr"><<a href="mailto:tanuk@iki.fi" target="_blank">tanuk@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 18, 2015, at 21:56, Sébastien Barthélémy wrote:<br>
> In some cases our application fails to get the stream latency: our<br>
> callback, which was set using pa_stream_update_timing_info(), is called<br>
> (in<br>
> stream_get_timing_info_callback  [1]) with o->stream->timing_info_valid<br>
> ==<br>
> FALSE.<br>
><br>
> My guess is that, in the test a bit above ([2]). we have<br>
> command==PA_COMMAND_TIMEOUT.<br>
><br>
> Is there any way to test that hypothesis?<br>
<br>
</span>The callback given to pa_stream_update_timing_info() has type<br>
pa_context_success_cb_t, which has the "success" argument. If "success"<br>
is false, you can get the error code with pa_context_errno(). If the<br>
operation failed due to a timeout, the error code should be<br>
PA_ERR_TIMEOUT.<br></blockquote><div><br></div><div>Thank you, I did the change, and so far only got timeouts.<br></div><div>Good news!<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>I don't know (or remember) the reason. I would guess that it has to do<br>
with maintaining a stable public API and avoiding unnecessary complexity<br>
in the API. However, if there's need for enabling the rtclock stuff for<br>
custom mainloops, I'd expect there to be some way to implement that<br>
without breaking backwards compatibility.<br></blockquote><div><br></div><div>Ok, I may give it a try (not sur I'll find the time).<br><br>Thank you for your help so far! <br></div></div></div></div>