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

[David Henningsson]

On 10/13/2013 09:54 AM, Tanu Kaskinen wrote:
> 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). 

I've never tried taking a monitor source of a filter sink, but I would
expect that it would output the filtered audio too.


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