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

[Tanu Kaskinen]

On Tue, 2013-10-01 at 15:39 +0200, David Henningsson wrote:
> On 10/01/2013 03:30 PM, Tanu Kaskinen wrote:
> > On Tue, 2013-10-01 at 15:09 +0200, David Henningsson wrote:
> >> On 10/01/2013 02:51 PM, Tanu Kaskinen wrote:
> >>> 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?
> > 
> > The filter sink creates a sink and a sink input as before, and requests
> > that a node is created for both. There's no need to explicitly connect
> > those two nodes - they will be connected by the fact that the filter
> > sink forwards the audio from the sink to its sink input, as it has
> > always done.
> > 
> > To allow a nice graph in a UI, the sink input node can indicate with an
> > extra pointer that it's really part of the same node as the sink node
> > and vice versa.
> > 
> > I do see the point of dual-direction nodes, and I'm starting to think
> > the idea should be tried out before committing to the solution of adding
> > the extra pointers between e.g. filter sinks and their sink inputs.
> > 
> > I added Janos to CC, in case he has some opinions about this.
> > 
> 
> I think one argument could be that detecting cycles becomes more elegant
> (and standard algorithms exists, etc). If we moved cycle detecting to
> the node layer, one could easily detect (and thus prohibit) a cycle made
> up of a null sink and a loopback, which I don't think we do today.

I see a big problem with filter sinks. They have two different
"outputs": the filtered audio (via a sink input) and unfiltered audio
(via a monitor source). If the whole thing is represented by only one
node, then there is ambiguity about what to do when someone requests
routing the audio from the filter sink to some other node.

There could still be cycle detection at the node level, even if we
create one output node and two input nodes for filter sinks. We should
anyway link the output node of a filter sink to the two input nodes,
it's just a different kind of a connection than the one that the routing
policy or the user deals with. The cycle detection code could treat the
two kind of connections as equal. (What to call the two connection
types? They are very different things... So far the normal "input to
output" connections have been called just "connections". The "output to
input" connections need some different name.)

-- 
Tanu