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. I have bad example, though: "what's the type and owner of the node, if it covers both a sink and a monitor source?" This is a bad example, because the current system with a single type and owner is broken anyway. A headset output on a typical phone can belong to two domains: the "pulse domain" and a "dsp domain". In the pulse domain the headset output is owned by a port, but in the dsp domain there's no sink (the audio comes directly from the cellular modem without pulseaudio ever seeing the audio samples), and therefore no port either, so the node type and owner is domain-dependent, that is, whoever wants to know the type or owner must ask that through an interface to which the caller provides the domain. It's not much of a leap then to make the type and owner also direction-dependent: just add a direction parameter to the "pa_node_get_owner()" function. -- Tanu
