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

[Arun Raghavan]

On Mon, 2013-09-23 at 12:50 +0300, 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.

Correct me if I'm mistaken, but the original intention that I recall was
for the routing layer to allow you to do routing from a source node to a
sink node, with the underlying implementation of that routing being the
loopback module.

Assuming this is how we want to work, I would argue that the resultant
sink-input/source-output should just be hidden from the user entirely.
IMO this is one of the nice bits of cleanup the node layer buys us, so
we should take advantage of this.

To my mind, this is not a regression, but a change in UI - the user's
interface for this changes from "move this sink input to this sink"
"remove the connection between these nodes, and add a connection between
these other nodes".

The regression here is the loss of this as an atomic operation - I don't
know how important that is. Any thoughts?

> 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.

Just to reiterate, I think we should only support operations that are
meaningful from a UX perspective (such as moving an application's sink
input to a new sink).

-- Arun