sink, source: Really set the fixed latency in set_fixed_latency_within_thread(),...
authorTanu Kaskinen <tanu.kaskinen@jollamobile.com>
Thu, 28 Mar 2013 15:30:15 +0000 (17:30 +0200)
committerTanu Kaskinen <tanuk@iki.fi>
Wed, 10 Apr 2013 13:30:01 +0000 (16:30 +0300)
commited51769a5932898e2d59b4fb326039fe7fd52c4c
tree6cd5408f1cff42160b150da54d53aa9781c2bc49
parent6745b1f97020fca84f6a55a87da8bb38f5b270ac
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".
src/pulsecore/sink.c
src/pulsecore/source.c