[pulseaudio-discuss] RFC: Public API for managing nodes

[Tanu Kaskinen]

On Tue, 2013-08-06 at 15:21 +0200, David Henningsson wrote:
> On 08/06/2013 02:54 PM, Tanu Kaskinen wrote:
> > On Tue, 2013-08-06 at 14:42 +0200, David Henningsson wrote:
> >> On 08/06/2013 02:30 PM, Tanu Kaskinen wrote:
> >>> On Tue, 2013-08-06 at 13:26 +0200, David Henningsson wrote:
> >>>> On 08/05/2013 01:37 PM, Tanu Kaskinen wrote:
> >>>>> On Wed, 2013-07-17 at 12:26 +0200, David Henningsson wrote:
> >>>>>> On 07/17/2013 11:22 AM, Tanu Kaskinen wrote:
> >>>>>>> On Wed, 2013-07-17 at 09:27 +0200, David Henningsson wrote:
> >>>>>>>> On 07/16/2013 03:20 PM, Tanu Kaskinen wrote:
> >>>>>>>>> What operations do you mean? Moving or removing a default connection is
> >>>>>>>>> not supported as such, but if the client tries that anyway, we can
> >>>>>>>>> implicitly convert the connection to an explicit one and disable default
> >>>>>>>>> connections, or we can require the client to do these operations
> >>>>>>>>> explicitly, but I think the latter would be too inconvenient for the
> >>>>>>>>> client.
> >>>>>>>>
> >>>>>>>> Ok, I think I didn't read the proposal well enough. Having done that, I
> >>>>>>>> understand that you're suggesting a global switch "default connections
> >>>>>>>> on/off" only. Or is it a per-node switch?
> >>>>>>>
> >>>>>>> It is a per-node switch.
> >>>>>>>
> >>>>>>>> I have another idea that might be worth considering: how about that the
> >>>>>>>> "explicit" layer can both enable and disable connections? So that there
> >>>>>>>> could be a default connection between A and B, but there is also some
> >>>>>>>> sort of explicit override that disables it. This would be more flexible
> >>>>>>>> than a more global on/off switch.
> >>>>>>>
> >>>>>>> I'm not sure what you mean. Do you perhaps mean that the default
> >>>>>>> connection on/off switch should be per-node (which it already is in my
> >>>>>>> proposal), or that it should be per-connection (so that if there are
> >>>>>>> multiple default from node A, it's possible to disable only a subset of
> >>>>>>> those)?
> >>>>>>>
> >>>>>>> I didn't make make it possible to disable individual default
> >>>>>>> connections, because I had a feeling that it would have very messy
> >>>>>>> semantics. If default connection from A to B is disabled, what is the
> >>>>>>> routing code supposed to do when conditions change and the default
> >>>>>>> routing is re-evaluated? Can it ever reactivate the connection between A
> >>>>>>> and B again? Is the per-connection disabling handled as a blacklist of
> >>>>>>> connections that must never be automatically activated?
> >>>>>>
> >>>>>> If the A -> B route is explicitly_disabled, that overrides any default 
> >>>>>> connections the routing system tries to make.
> >>>>>
> >>>>> What is the use case for explicitly disabled connections? I'll assume
> >>>>> here that your idea was to allow moving a default connection elsewhere
> >>>>> (making the connection explicit in the process) without disabling all
> >>>>> default connections for the node.
> >>>>>
> >>>>> When the user moves a default connection, the routing system obviously
> >>>>> shouldn't immediately create another default connection elsewhere to
> >>>>> replace the disabled connection.
> >>>>>
> >>>>> On the other hand, if the routing system doesn't create replacement
> >>>>> connections, then that results in weird behaviour. Let's say that
> >>>>> there's a default connection A -> B, and the user moves the connection
> >>>>> to A -> C. Then B disappears. The routing changes its opinion of the
> >>>>> best available routing for A, which might be D. So removing node B
> >>>>> resulted in audio suddenly appearing in node D, even though nothing was
> >>>>> playing to B.
> >>>>>
> >>>>
> >>>> Assume your example of a default connection A -> B which the user
> >>>> changes into A -> C, by adding an explicit A -> C connection. Without
> >>>> some sort of explicitly_disabled blacklist that would then include A ->
> >>>> B, the routing system would be free to route A to *both* B and C.
> >>>
> >>> My solution is that the application disables the default routing
> >>> altogether for A, if it doesn't want to have the default connection A ->
> >>> B. It seems to me that this causes fewer surprises than the blacklisting
> >>> approach.
> >>>
> >>>> Whether this is implemented as a bool flag or as a separate blacklist is
> >>>> an implementation detail, but a bool flag just seemed simpler and faster
> >>>> to me, than having to look in several lists to figure out whether a
> >>>> connection exists or not.
> >>>
> >>> You don't need to look in several lists to figure out whether a
> >>> connection exists or not. If we have connection objects, which I think
> >>> we both want to have, it's enough to get the list all connections and
> >>> see whether a particular connection is included in that list.
> >>>
> >>
> >> Okay, so let me see if I understand this right. You propose that you can
> >> add explicit connections between two specified nodes, but blacklisting
> >> default connections have to be done on a node wide level (rather than
> >> per connection).
> >>
> >> That sounds interesting, as it would be more resilient towards nodes
> >> appearing and disappearing later on.
> >> I think that blacklisting would have to be two booleans per node though,
> >> one for outgoing connections and one for incoming. And a connection
> >> cannot exist if it is blocked on *either* side, rather than both sides.
> >> Does that make sense?
> > 
> > My plan has so far been to only disable outgoing default connections,
> > but if there's need for it, I don't see any problem with adding another
> > bool for disabling incoming default connections. Do you have a use case?
> > 
> 
> Well, what's outgoing for playback is incoming for recording, so I think
> this would be the corresponding use case: assume a user changes from B
> -> A to C -> A, and that later on, a new source D appears. Then you
> would want to disable A on the incoming side to avoid a new D -> A
> connection?

Ok, I misunderstood what you meant by incoming and outgoing. Since a
node can't be both an input and output node, it can never have both
incoming and outgoing connections in the audio flow direction sense. I
thought that by "incoming" you meant connections that are initiated by
other nodes, and by "outgoing" I thought you meant connections that are
initiated by the node itself. That is, "incoming" and "outgoing"
wouldn't have anything to do with audio flow direction.

In your example, are B, C and D sources, and is A a capture stream? And
B -> A was a default connection initiated by A? If so, I would do the
move from B -> A to C -> A so that default connections are disabled for
A, and an explicit connection is added from C to A.

D probably won't initiate any default connections (sources and sinks
usually don't do that), but if it does initiate a default connection to
A, I think it's more likely that it should be allowed (this would be
pretty unusual routing rule, though, and you didn't explain why the D ->
A connection would be created, so it's hard to say anything with great
confidence).

-- 
Tanu