<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - It's possible to create audio loops with module-loopback"
href="https://bugs.freedesktop.org/show_bug.cgi?id=61880">61880</a>
</td>
</tr>
<tr>
<th>CC</th>
<td>lennart@poettering.net
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pulseaudio-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>It's possible to create audio loops with module-loopback
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>pulseaudio-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Reporter</th>
<td>tanuk@iki.fi
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>core
</td>
</tr>
<tr>
<th>Product</th>
<td>PulseAudio
</td>
</tr></table>
<p>
<div>
<pre>It's possible to create loops with module-loopback. By loops I mean a situation
where the same audio circulates within the system forever (and probably gets
infinitely amplified as a result).
For example: there are two hardware sinks: hw_sink_H1 and hw_sink_H2. Then
there is a filter sink filter_sink_F connected to hw_sink_H1, and a loopback
from hw_sink_H2's monitor to filter_sink_F:
+-------------+ +----------+
+-->|filter_sink_F|-->|hw_sink_H1|
| +-------------+ +----------+
|
| +------------------+
| | hw_sink_H2 |
| | - - - - - - - - -|
+---------------------|hw_sink_H2.monitor|
+------------------+
This works fine. Now, filter_sink_F is moved to hw_sink_H2:
+----------+
|hw_sink_H1|
+----------+
+-------------+ +------------------+
+-->|filter_sink_F|-->| hw_sink_H2 |
| +-------------+ | - - - - - - - - -|
+---------------------|hw_sink_H2.monitor|
+------------------+
This configuration is obviously broken. But what could we have done? Neither
the sink input nor the source output of module-loopback was moved, so the
may_move_to() callbacks were never called. Even if module-loopback could have
detected the loop, what should it have done? It could have prevented the move,
or it could have disabled itself. Neither options sounds particularly good.
The best solution that I can think of is to get rid of all the filter sinks and
sources. There would still be possibilities for loops, for example by using two
loopbacks to cross-connect two sinks by using their monitor sources, but I
believe those cases are preventable. Regarding the feasibility of getting rid
of the filter sinks and sources: DSP filters could be handled by attaching them
directly to arbitrary streams and devices, and remapping and combining could be
integrated in the core so that separate sinks/sources wouldn't be needed.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>