On Mon, 2018-07-02 at 15:22 +0300, Juho Hämäläinen wrote: > If the interaction state would be reset when ducking, it could happen > that we apply volume factor to a sink-input that already has volume > factor applied by us. For example when volume factor is applied while > a sink-input is running and the sink-input is moved to another sink, > there will be assertion failure from pa_sink_input_add_volume_factor() > when calling pa_hashmap_put(). > > Signed-off-by: Juho Hämäläinen <jusa at hilvi.org> > --- > src/modules/stream-interaction.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/modules/stream-interaction.c b/src/modules/stream-interaction.c > index 4184786..88cbd5d 100644 > --- a/src/modules/stream-interaction.c > +++ b/src/modules/stream-interaction.c > @@ -243,7 +243,10 @@ static pa_hook_result_t process(struct userdata *u, pa_sink_input *i, bool creat > pa_assert(u); > pa_sink_input_assert_ref(i); > > - if (!create) > + /* Reset interaction states only for cork/mute. If we would reset interaction state > + * for ducking, we could apply volume factor to sink-input that already has volume > + * factor applied by us. */ > + if (!u->duck && !create) > for (j = 0; j < u->n_groups; j++) > pa_hashmap_remove(u->groups[j]->interaction_state, i); I would be in favour of removing this code altogether. It has only effect on moving streams that we have muted/corked, and the effect is (if I understand the code correctly) to re-mute/cork the stream when starting the move, which doesn't really make sense to me. Maybe there is some valid reason for doing it, but I don't think it's a good policy to keep undocumented code around just in case, if the code seems to be doing nonsensical things. If removing the code seems too risky, I can also apply this patch and then add a comment that explains that nobody really knows what the purpose of the code is. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
