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

[Tanu Kaskinen]

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.

-- 
Tanu