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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
