On 10/13/2013 02:59 PM, Tanu Kaskinen wrote: > On Sun, 2013-10-13 at 13:37 +0200, David Henningsson wrote: >> On 10/13/2013 09:54 AM, Tanu Kaskinen wrote: >>> On Tue, 2013-10-01 at 15:39 +0200, David Henningsson wrote: >>>> I think one argument could be that detecting cycles becomes more elegant >>>> (and standard algorithms exists, etc). If we moved cycle detecting to >>>> the node layer, one could easily detect (and thus prohibit) a cycle made >>>> up of a null sink and a loopback, which I don't think we do today. >>> >>> I see a big problem with filter sinks. They have two different >>> "outputs": the filtered audio (via a sink input) and unfiltered audio >>> (via a monitor source). >> >> I've never tried taking a monitor source of a filter sink, but I would >> expect that it would output the filtered audio too. > > Well, it doesn't. The data to monitor sources come from > pa_sink_render(), which is called before the filter sink has a chance to > do anything with the data. I suspect that the idea of monitor sources was implemented before the idea of filter sinks, and this is an unwanted side effect of that. Anyway, I wonder if this would be easy to change, because currently it seems a bit stupid IMO - it would be more useful to have the filtered output through the monitor sources. If not, I think you need to model this scenario as two nodes, one for the mixer and one for the filter (and report back with an error if somebody tries to remove the connection between the mixer and the filter). -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
