Bug 61880 - It's possible to create audio loops with module-loopback
Summary: It's possible to create audio loops with module-loopback
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-05 23:38 UTC by Tanu Kaskinen
Modified: 2018-07-30 09:33 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Tanu Kaskinen 2013-03-05 23:38:30 UTC
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.
Comment 1 GitLab Migration User 2018-07-30 09:33:13 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/7.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.