[pulseaudio-discuss] Using nodes as the primary routing mechanism
Tanu Kaskinen
tanu.kaskinen at linux.intel.com
Mon Sep 23 02:50:01 PDT 2013
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.
--
Tanu
More information about the pulseaudio-discuss
mailing list