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? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
