On 10/01/2013 02:51 PM, Tanu Kaskinen wrote: > On Tue, 2013-10-01 at 13:12 +0200, David Henningsson wrote: >> On 09/23/2013 11:50 AM, Tanu Kaskinen wrote: >>> Hi all, >>> >>> With nodes, there will be two routing layers: the higher-level node >>> layer and the lower-level layer with sink inputs, sinks etc. The user >>> will be able to still use the old "move sink input" interface, but what >>> to do if the user tries to move a sink input that has a node to a sink >>> that doesn't have a node? From the node layer point of view the sink >>> input is not routed anywhere. Normally, if a sink input node is not >>> routed anywhere, the routing system will connect the sink input to a >>> private null sink (the null sink is dynamically created for the sink >>> input, is not used for anything else, and doesn't have a node). However, >>> in this case the sink input should not be connected to the null sink, >>> but to the sink that the user specified. Respecting the user choice >>> would require some extra complexity in the routing system. >>> >>> My proposal is to avoid this complexity by not allowing the user to >>> route sink inputs with a node to sinks without a node, and also by >>> completely preventing the user from controlling the routing of sink >>> inputs that don't have a node. This would mean that we can map all valid >>> sink input move requests to node operations, because both the sink input >>> and the target sink would always have a node. >>> >>> A consequence of this proposal would be that I should implement a node >>> for every sink and sink input in the current code base, including >>> monitors and loopbacks etc., because otherwise there would be >>> regressions for users. I was originally hoping that I could postpone >>> that work for some later time (or in the best case, avoid that work >>> completely). For example, I was planning not to implement nodes for the >>> streams of module-loopback, but if I don't do that, then there will be a >>> regression: it was previously possible for users to move the sink input >>> and source output of module-loopback, but without nodes for the sink >>> input and source output that wouldn't be possible. This wouldn't mean >>> that every loopback would have to have nodes for the streams: loopbacks >>> created by the routing system itself don't need nodes, but >>> module-loopback instances loaded by users do need nodes. >>> >>> In conclusion: I'm proposing that nodes will be the primary routing >>> mechanism, and the old non-node-aware routing interfaces will be >>> implemented on top of the node interfaces, not side-by-side. Operations >>> where the translation can't be done will simply fail. Regressions can be >>> avoided by creating nodes for all entities that were user-routable >>> before. >>> >> >> Sorry for the late answer. The plan you're now suggesting is more in >> line with what I thought originally, and also, I think it is a better >> architecture. >> >> This also turns the node routing layer into a more complete graph as >> nodes can be both input and output nodes. If a sink is a node, then it >> would both be able to take audio from its sink inputs, as well as give >> audio to its monitors, i e, both an input and output node. Is that a >> correct understanding? > > 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? I guess it has just been more logical for me to think as "one item - one node", and I've familiar with the DAG concept [1] and there's some graph theory behind that, but I don't feel very strongly about having just one node either if there's a good reason to do otherwise. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic [1] http://en.wikipedia.org/wiki/Directed_acyclic_graph
