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

KimJeongYeon see2002 at gmail.com
Wed Apr 19 08:24:04 UTC 2017

2017. 4. 19. 오전 5:10에 "Georg Chini" <georg at chini.tk>님이 작성:

On 18.04.2017 21:45, Georg Chini wrote:

> On 18.04.2017 14:36, KimJeongYeon wrote:
>> For example, a normal stream tried to attach to filter sink or source,
>> which
>> filter loaded and managed by filter-apply. But, the stream goes to
>> filter's
>> ***master sink or source*** due to unexpected restoring operation.
>> It should attached to filter sink or source properly.
>> Also, includes further fix according to Georg's comment, [1]
>>    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.
>> [1] https://lists.freedesktop.org/archives/pulseaudio-discuss/20
>> 17-April/027980.html
>> Signed-off-by: KimJeongYeon <jeongyeon.kim at samsung.com>
> Hi JeongYeon,
> sorry, but I still don't agree with your patch. As already said you do not
> need the
> enumeration, a simple boolean

Ok. I'll do.

should do. Also skip_prop_change seems unnecessary.

About 'skip_prop_change':
Move operation happens twice when call 'move_objects_for_filter'. Because,
unexpected proplist-hook comes at 'do_move'.
But, it doesn't harm moving operation.
It would be remove 'skip_prop_change'.

I would name the new property filter.apply.mfa_loaded because the other
> properties
> have a filter.apply prefix (although I suggested the other name myself).
> I think the following logic is much simpler than your approach and still
> covers all cases
> (I always wrote sink but naturally the same applies for the source).
> Please correct
> me if I have overlooked anything.
> static pa_hook_result_t process(struct userdata *u, pa_object *o, bool
> is_sink_input) {
>    ... leave the first bit unchanged ...
>     /* Check if filter.apply property is set and get filter name. */
>     if ((want = get_filter_name(o, is_sink_input))) {
>         /* We end up here, when filter.apply is set */
>         /* If module is not set, we don't know which type of sink we are
> on,
>          * therefore do not try to do anything. (Not sure if this is
> right. The
>          * filter sinks should always have module set, so we could conclude
>          * that unset means that we are not on a filter sink and can just
> skip
>          * the next check. But let's leave it like it is for the moment.)
> */
>         if (!module)
>             goto done;
>         /* If we are already on the right filter sink, we don't need to do
> anything */
>         module_name = pa_sprintf_malloc("module-%s", want);
>         if (pa_streq(module->name, module_name)) {
>             pa_log_debug("Stream appears to be playing on an appropriate
> sink already. Ignoring.");
>             goto done;
>         }
>         /* Now filter apply is set and the sink is not the right filter
> sink.
>          * We have two possible cases left: */
>         /* 1) The stream has filter.apply.mfa_loaded set. This means the
> stream has been
>          *      manually moved away from the filter. */
>         if (property filter.apply.mfa_loaded) {

I have forgotten one possible case here: The stream may have moved from one
filter sink to another.
In this case, filter.apply should be changed to the new filter and
filter.apply.mfa_loaded should not be
removed. So it should be:

                if (sink is filter sink) {
                    change filter.apply
                } else {
                    remove filter.apply
                    remove filter.apply.mfa_loaded
                keep sink as is

instead of

            Remove filter.apply
>             Remove filter.apply.mfa_loaded
>             keep sink as is

Your logic seems fine for me.
I'll submit patch soon.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20170419/b9a55c02/attachment.html>

More information about the pulseaudio-discuss mailing list