This gets rid of an error message from the debug log. If
volume_factor_source would actually be used somewhere, this bug would
have caused more severe problems.
volume_factor_source should have the source's channel map. When moving
the stream, the volume needs to be remapped from the old source's
channel map to the new source's map. However, when the stream is being
moved, there is a period where the old source has already been
forgotten and the new source isn't yet known, so the remapping can't
be done directly between the two channel maps. Instead, the volume is
remapped from the old source's map to the stream's own map when the
move starts, and again remapped from the stream's map to the new
source's map when the move finishes.
The first remapping was missing, causing the second remapping fail and
print an error to the log.
(I checked the sink input code as well. It didn't have this bug.)
---
src/pulsecore/source-output.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/pulsecore/source-output.c b/src/pulsecore/source-output.c
index 26a7123..5cf551f 100644
--- a/src/pulsecore/source-output.c
+++ b/src/pulsecore/source-output.c
@@ -1242,6 +1242,9 @@ int pa_source_output_start_move(pa_source_output *o) {
pa_assert_se(pa_asyncmsgq_send(o->source->asyncmsgq, PA_MSGOBJECT(o->source), PA_SOURCE_MESSAGE_REMOVE_OUTPUT, o, 0, NULL) == 0);
pa_source_update_status(o->source);
+
+ pa_cvolume_remap(&o->volume_factor_source, &o->source->channel_map, &o->channel_map);
+
o->source = NULL;
pa_source_output_unref(o);
--
2.6.4
