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

[Tanu Kaskinen]

On Mon, 2013-08-12 at 13:45 -0500, Pierre-Louis Bossart wrote:
> > When you say "can't be represented", do you mean internally in the
> > server, or in the client API? Internally there will certainly be
> > knowledge about the conflicts. The plan is to keep this knowledge in the
> > node backend code, e.g. in the alsa modules. There won't be any generic
> > representation of the conflict information. Instead, the generic routing
> > code will try to activate a set of nodes, and if the backend says "no
> > can do", then the routing code will try the next best set of nodes.
> >
> > To clients the conflicts will only be visible so that if they try to
> > activate two conflicting nodes at the same time, the operation fails.
> 
> I think I am confused by the 'explicit' and 'default' routing. It looks 
> to me that the 'explicit' routing performed by a client is a means to 
> extend the audio policy (play to more than one default output). In that 
> case, I believe you should only expose to the client the nodes than can 
> be used given the current audio policy+hardware constraints, rather than 
> reporting an error.

The explicit routing is a means of overriding the default routing. If
the client requests an additional route to a node that conflicts with a
node that is used by the default routing, the client request will be
fulfilled with higher priority, so the existing connection will be
removed. It's the default routing that adapts to constraints set by
clients, not the other way around.

> What would the client do if the operation fails? 
> Make it simple and add a tag in the pa_node_info to report that a given 
> node is currently not available. This could be used to expose conflicts 
> without given any details and also handle digital passthrough outputs 
> (one connection only). You could also have a callback saying when a node 
> became available again so that clients can update their routing, if needed.

I don't want to mark nodes unavailable just because they can't be used
simultaneously with the currently active nodes. We could mark a node so
that clients could see that routing to that node would have a side
effect of disabling some of the current connections, but I don't want to
do that before a UI designer tells me that they really want to have that
information.

My reluctance to exposing the conflict information is that in theory the
conflict rules can be arbitrarily complex, and I don't know how specific
the clients need the conflict representation to be. For a relatively
simple example, there could be three outputs, A, B and C, and it might
be possible to use any two of them simultaneously, but not all three of
them. Should the conflict API describe these node relationships fully,
or would it be enough, in case two of the nodes are already in use, to
mark the remaining node as "activating this node will conflict with some
of the existing connections"? I have no idea. So far I don't have
evidence that any conflict information is necessary, so the best way
forward seems to not provide any conflict API at all at this point.

-- 
Tanu