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

[Tanu Kaskinen]

On Thu, 2013-10-17 at 19:47 +0530, Arun Raghavan wrote:
> 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.

Yes, the streams should be hidden (I don't know about "entirely", do you
mean that "pactl list" wouldn't show them either?) if the loopback was
loaded as a result of the user using the new routing interface. If the
user loaded module-loopback manually, then I'd argue that the streams
should still be user-routable. Implementing the backwards compatibility
is almost trivial.

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

The regression is the need for the user to figure out why doing what he
has always done doesn't work, or why the instructions found on some
random web page don't work.

As for the loss of atomicity - it's possible for the UI to implement a
"move connection" operation if it wants. The client API will support
doing "remove+add" operations atomically.

-- 
Tanu