[pulseaudio-discuss] [PATCH 17/25] raop: Resume smoother for correct latency calculation

[Hajime Fujita]

When a state transits to PA_SINK_RUNNING, the previous state
could be PA_SINK_IDLE. The current code failed to resume smoother
in such a case. Failure to resume smoother led to calculate wrong
latency in sink_get_latency(), because pa_smoother_get() returned
a garbage value.

In fact, it is safe to call pa_smoother_resume() regardless of the
current smoother suspension state. It checks the suspension state
and does nothing if already resumed.

This patch always resumes smoother at PA_SINK_RUNNING, so that
sink_get_latency() calculates correct (or at least, somewhat
reasonable) latency values.
---
 src/modules/raop/module-raop-sink.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/modules/raop/module-raop-sink.c b/src/modules/raop/module-raop-sink.c
index d49877d..c6008e9 100644
--- a/src/modules/raop/module-raop-sink.c
+++ b/src/modules/raop/module-raop-sink.c
@@ -310,9 +310,10 @@ static int udp_sink_process_msg(pa_msgobject *o, int code, void *data, int64_t o
                     break;
 
                 case PA_SINK_RUNNING:
-                    if (u->sink->thread_info.state == PA_SINK_SUSPENDED)
-                        pa_smoother_resume(u->smoother, pa_rtclock_now(), true);
                     pa_log_debug("RAOP: RUNNING");
+
+                    pa_smoother_resume(u->smoother, pa_rtclock_now(), true);
+
                     if (!pa_raop_client_udp_can_stream(u->raop)) {
                         /* Connecting will trigger a RECORD */
                         pa_raop_client_connect(u->raop);
-- 
1.8.1.2