On Mon, 2013-08-05 at 12:56 -0500, Pierre-Louis Bossart wrote: > On 7/13/13 10:48 AM, Tanu Kaskinen wrote: > > Hi all, > > > > I've written up a proposal for a public API for controlling routing with > > nodes: > > http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/RoutingAPI/ > > > > Comments would be very welcome. > > Thanks Tanu. > Can you clarify the differences between nodes and existing > sink/sink_input/source/source_output structures? 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. > 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. -- Tanu
