On 07.02.2018 13:21, Tanu Kaskinen wrote:
On Tue, 2018-02-06 at 20:26 +0100, Georg Chini wrote:
When module-filter-apply tries to find a matching source-output for
a given sink-input and a stream with the same role
Shouldn't this be "with the same group", not "with the same role"?
Yes, you are right. I was thinking of the special case where
the streams specify media.role. In that case, streams that
have the same role are in the same group.
exists on the
monitor source of the filter, module-filter apply falsely assumes
that the source belongs to another instance of the filter and tries
to access source->output_from_master->source, which leads to a
segmentation fault.
This patch fixes the issue by ignoring the stream if the source is
the monitor source of the filter.
Is ignoring the stream really the right solution? Previously any source
output in the same group as the sink input would be accepted, no matter
how it was routed. If the source output was already routed to the
correct filter, then we'd pick the master source through
"output_from_master", and if the source output was not correctly routed
yet, we'd pick the current source as the master.
In this case the source output is wrongly determined as "already
correctly routed", so shouldn't we fix the issue by setting the current
source as the master source, like in all other cases where the source
output is not yet correctly routed? No, because we can't make the
filter source use the filter sink's monitor as the master source. It
seems that the correct solution would be to find the filter source that
corresponds to the filter sink, and then use "output_from_master" to
set the master source. In case you don't follow, I'll put some code
below:
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=104958
---
src/modules/module-filter-apply.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/modules/module-filter-apply.c
b/src/modules/module-filter-apply.c
index 783d85ed..163d52a2 100644
--- a/src/modules/module-filter-apply.c
+++ b/src/modules/module-filter-apply.c
@@ -259,6 +259,12 @@ static bool find_paired_master(struct userdata *u, struct
filter *filter, pa_obj
if (pa_streq(g, group)) {
if (pa_streq(module_name, so->source->module->name)) {
+ /* Make sure we are not routing to the monitor source
+ * of the same filter */
+ if (so->source->monitor_of) {
+ pa_xfree(g);
+ continue;
+ }
So I'd do this instead:
/* The source output is currently routed to the monitor
* source of the filter. We can't use the monitor source
* of the same filter as the master source. Let's find
* the real source of the filter, and then use its master
* source. */
if (so->source->monitor_of) {
pa_source *source;
PA_IDXSET_FOREACH(source, u->core->sources, idx) {
if (source->module == so->source->monitor_of->module &&
source->output_from_master) {
filter->source_master = source->output_from_master->source;
break;
}
}
}
I was looking for some way to figure out what the right source might be,
but I do not think the information is sufficient. Consider you have a
loopback
running from the monitor source to some other sink and have specified
media.role=phone for the loopback. Then the stream is completely unrelated
to what you are trying to filter. Also, specifying the monitor source of a
filter as the master source does not make a lot of sense from the user
perspective, so I concluded that in this case there must be another reason
why the monitor stream is in the same group and therefore decided to ignore
it. Another possibility would be to return false if the monitor source is in
the same group, but that seems too restrictive.
I am however not sure what is the correct way to solve it, so if you still
believe that your way is best, I can change the patch accordingly.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
