> Nodes represent the logical routing endpoints. Sinks etc. can expose a > node, but not all of them do. For example, we want to allow routing one > input node to multiple output nodes, and this might require a combine > sink to be created, but this automatic combine sink shouldn't appear as > a node. > >> seems to me that >> 'nodes' could also mean a change in audio profiles, eg the headset is >> really an audio codec attribute and routing to the headset isn't >> necessarily a change of routing within PulseAudio. > > The headset would have a port in PulseAudio, and that port would be > exposed as a node. Routing to that node causes the port to be activated. So if I have a virtual sink with some sort of processing and I want to hear the result on the headset, how does it work? It's not clear to me that you can always think in terms of endpoints for routing. Likewise for something like acoustic echo cancellation how would you trap the echo reference? >> There are also cases where an output cannot be used because of the setup >> of another output, eg when it's physically muxed with something else or >> it depends on a clock defined elsewhere. How are physical constraints >> reported to the user? > > That's a good question. Currently the constraints aren't visible to > clients. If a UI developer shows up and tells that he/she needs the > conflict information, then we have to come up with something. It would > be simple to just attach a list of conflicting nodes to the node > structure, but I'm afraid the conflicts aren't always that simple. You have one right there for local outputs, most solutions provide access to the headset or to the speaker, not to both. If this simple conflict between 'nodes' can't be represented then I wonder how practical this solution is.
