[pulseaudio-discuss] Using nodes as the primary routing mechanism

[David Henningsson]

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