Bug 61880

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.