On 08.02.2018 17:09, Tanu Kaskinen wrote:
On Wed, 2018-02-07 at 15:28 +0100, Georg Chini wrote:
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.
The loopback stream in your example shouldn't be in any filter group,
so it shouldn't cause any confusion when resolving the master source.
Is this loopback example something that was actually observed in the
bug?
No, it wasn't. In that case the cause was an application (zoiper) which
seems to be testing different combinations of source and sink if I read
the log right. So the bug report falls into the category "user error"
because the application is trying a combination of source/sink which
does not make sense.
In fact I read the code wrong - my loopback example does not work because
the loopback would also need to have the filter.apply property set to the
same filter in addition to having the same role. So forget the example.
Anyway, I decided to ignore the stream because I could only see two
possible reasons why the monitor stream can be in the same group:
1) User error: Then, when the stream is ignored, find_paired_master()
will return false because it does not find a matching stream. In my
opinion this is OK because the user specified a sink/source combination
which cannot work (and we cannot really figure out, which source the
user actually wanted).
2) A weird setup, so that the monitor stream is in the same group more
or less by accident. Then, when the stream is ignored, find_paired_master()
should find the correct stream later.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
