On Tue, 2013-08-06 at 15:21 -0500, Pierre-Louis Bossart wrote: > >> 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? If all audio to the headset should be filtered, then the headset node should arrange things behind the scenes so that audio routed to it passes through a filter first. If you want to have "headset" and "filtered headset" as separate routing targets, then you can create two nodes. I hope that wasn't too hand-wavy. I don't plan to implement the code for "arranging things behind the scenes" in the near future, and I don't have exact plans for how to do it, but it doesn't seem like an impossible task at all. Having a separate node for "filtered headset" should be much easier - just create a node for the filter sink. > >> 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. 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. -- Tanu
