sink, source: Really set the fixed latency in set_fixed_latency_within_thread(), always.

The old assumption seemed to be that if a sink or source has the
DYNAMIC_LATENCY flag set, it can never change, so the fixed latency
will always be zero. This assumption doesn't hold with filter sinks
and sources that are moved around.

This fixes a crash with two module-virtual-sink instances on top of
each other, when the bottom one is moved from a sink without dynamic
latency to a sink with dynamic latency. What happened was that first
the bottom virtual sink "updated" (due to this bug nothing was
actually updated) its fixed latency to match the master sink (zero
fixed latency), and then the top virtual sink updated its fixed
latency to match the master sink. The master sink was the bottom
virtual sink, whose fixed latency should have been set to zero, but it
was not, so the pa_sink_set_fixed_latency_within_thread() failed in
the assertion "latency == 0".

1 files changed, 2 insertions, 0 deletions

diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
index fb2e14b2..6724c4bb 100644
--- a/src/pulsecore/source.c
+++ b/src/pulsecore/source.c
@@ -2528,6 +2528,8 @@ void pa_source_set_fixed_latency_within_thread(pa_source *s, pa_usec_t latency)
 
     if (s->flags & PA_SOURCE_DYNAMIC_LATENCY) {
         pa_assert(latency == 0);
+        s->thread_info.fixed_latency = 0;
+
         return;
     }