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".
---
src/pulsecore/sink.c | 5 +++++
src/pulsecore/source.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index 89273c8..824cb31 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
@@ -3261,6 +3261,11 @@ void pa_sink_set_fixed_latency_within_thread(pa_sink *s, pa_usec_t latency) {
if (s->flags & PA_SINK_DYNAMIC_LATENCY) {
pa_assert(latency == 0);
+ s->thread_info.fixed_latency = 0;
+
+ if (s->monitor_source)
+ pa_source_set_fixed_latency_within_thread(s->monitor_source, 0);
+
return;
}
diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
index 45923b2..218aa57 100644
--- a/src/pulsecore/source.c
+++ b/src/pulsecore/source.c
@@ -2547,6 +2547,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;
}
--
1.7.10.4
