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

[Pierre-Louis Bossart]

> 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. 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.
Cheers,
-Pierre