[pulseaudio-tickets] [Bug 61880] New: It's possible to create audio loops with module-loopback

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=61880

          Priority: medium
            Bug ID: 61880
                CC: lennart at poettering.net
          Assignee: pulseaudio-bugs at lists.freedesktop.org
           Summary: It's possible to create audio loops with
                    module-loopback
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: tanuk at iki.fi
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: core
           Product: PulseAudio

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20130305/ff61b929/attachment.html>