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

[David Henningsson]

On 10/01/2013 02:51 PM, Tanu Kaskinen wrote:
> 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.

So a filter sink, which both consumes and produces audio data, would
then have two nodes instead, one for input and one for output? Could you
elaborate on this, i e, how these two nodes (belonging to the same
filter sink) are connected to each other?

I guess it has just been more logical for me to think as "one item - one
node", and I've familiar with the DAG concept [1] and there's some graph
theory behind that, but I don't feel very strongly about having just one
node either if there's a good reason to do otherwise.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] http://en.wikipedia.org/wiki/Directed_acyclic_graph