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
