[pulseaudio-discuss] [PATCH] filter-apply: Fixed a stream moves to wrong sink(or source).

[KimJeongYeon]

2017-04-11 23:42 GMT+09:00 Georg Chini <georg at chini.tk>:
> sorry, but it still does not look right to me. Now you always remove the
> filter.apply
> property when the stream is moved away. This should only be done for streams
> that have been moved to the filter sink/source and did not have filter.apply
> set initially.
>
> That's why I said you need an additional flag to mark those streams where
> the property
> has been set by module-filter-apply.
>
> If a stream that had filter.apply set initially is moved to another
> sink/source, then the filter
> should be applied again (a new filter, since the master sink/source has
> changed).
>
> If a stream that did not have filter.apply set initially is moved away, the
> property should
> be removed and no new filter applied.
>
> Also, a property list change might add or remove the filter.apply property.
> If it is added,
> we want that the filter is applied. Your patch does nothing and assumes that
> the stream
> is already filtered, even if the stream is not on a filter sink.
>
>
> So the overall logic is as follows (assuming that filter.mfa_added is the
> flag that indicates
> whether module-filter-apply has set the filter.apply property):
>
> 1) If a stream with filter.apply set and filter.mfa_added unset is moved/put
> to a non-filter
> sink, the filter should be applied. This is also true, if the stream is
> moved away from
> another filter sink. From the stream perspective it just means that the
> master sink has
> changed.
>
> 2) If a stream with filter.apply unset is moved/put to a filter sink,
> module-filter-apply should
> set the filter.apply and the filter.mfa_added properties. Because the stream
> is already at the
> right sink then, nothing else needs to be done.
>
> 3) If a stream with both, filter.apply set and filter.mfa_added set, is
> moved to a non-filter sink,
> the two properties should be removed. The stream is already at the right
> sink then, so
> nothing else needs to be done.
>
> 4) If the filter.apply property is added/removed manually and so causes a
> proplist_change
> event, the filter should be added/removed. We can always unset
> filter.mfa_added in that
> situation because then the user chose what is needed. All other proplist
> changes can be
> safely ignored (meaning that if the stream is already filtered and
> filter.apply is set or the
> stream is not filtered and filter.apply is unset we don't need to do
> anything).
>
> I hope this is clarifies the approach. If you are unsure or do not
> understand what I mean,
> please contact me on IRC and we can discuss it further.
>
> Regards
>              Georg
>

Hi Georg and developers,

Sorry. I couldn't feedback promptly due to personal reason.
I understand what you explained. Then, it is clear for me how to fix
toward. Thanks.

I've submit a new version of patch just ago.
Link : https://patchwork.freedesktop.org/patch/151011/

Would you please review again the patch?
There might be missed scenarios or unexpected operations due to little
bit complex of solution. But, it works fine in my local develop
environment. :-)

Any feedback or suggestions are welcome.

Regards,
KimJeongYeon