On 19.04.2017 10:24, KimJeongYeon wrote:
2017. 4. 19. 오전 5:10에 "Georg Chini" <[email protected]
<mailto:[email protected]>>님이 작성:
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/2017-April/027980.html
<https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-April/027980.html>
Signed-off-by: KimJeongYeon <[email protected]
<mailto:[email protected]>>
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.
That's what I mean. I know there will be an unnecessary call to
process() due to
the property list change, but it should not have any effect and so there
is no need
to prevent it. Actually the move operation should not happen twice,
instead you
should see the "Stream appears to be playing on an appropriate sink
already. Ignoring."
message. Or am I wrong there?
Apart from PA_PROP_FILTER_APPLY_MOVING there are also the other changes
to the
property list when we set/remove the filter.apply and
filter.apply.set_by_mfa properties.
They also should have no effect, but better test it out. If there are
too many superfluous
messages in the log, I am not completely against using skip_prop_changes
to suppress
them. In this case you would only need to set the variable before the
property list
operation and it can be checked and reset early in process().
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
