On 10/13/2013 09:54 AM, Tanu Kaskinen wrote: > On Tue, 2013-10-01 at 15:39 +0200, David Henningsson wrote: >> On 10/01/2013 03:30 PM, Tanu Kaskinen wrote: >>> On Tue, 2013-10-01 at 15:09 +0200, David Henningsson wrote: >>>> On 10/01/2013 02:51 PM, Tanu Kaskinen wrote: >>>>> I did not plan to allow dual-direction nodes. If you want to represent >>>>> sinks as dual-direction nodes in a UI, I'm fine with adding information >>>>> to the nodes that allows the UI to do the correlation. I'm less >>>>> enthusiastic about doing the merging in the core. That said, I don't >>>>> have better arguments for this than that "allowing dual-direction nodes >>>>> may cause complications", and I don't have good examples of such >>>>> complications at this point, so I may change my opinion. >>>> >>>> So a filter sink, which both consumes and produces audio data, would >>>> then have two nodes instead, one for input and one for output? Could you >>>> elaborate on this, i e, how these two nodes (belonging to the same >>>> filter sink) are connected to each other? >>> >>> The filter sink creates a sink and a sink input as before, and requests >>> that a node is created for both. There's no need to explicitly connect >>> those two nodes - they will be connected by the fact that the filter >>> sink forwards the audio from the sink to its sink input, as it has >>> always done. >>> >>> To allow a nice graph in a UI, the sink input node can indicate with an >>> extra pointer that it's really part of the same node as the sink node >>> and vice versa. >>> >>> I do see the point of dual-direction nodes, and I'm starting to think >>> the idea should be tried out before committing to the solution of adding >>> the extra pointers between e.g. filter sinks and their sink inputs. >>> >>> I added Janos to CC, in case he has some opinions about this. >>> >> >> 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. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
