> 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
