[pulseaudio-discuss] RCF: Public API for managing nodes
Tanu Kaskinen
tanu.kaskinen at linux.intel.com
Mon Aug 5 22:19:55 PDT 2013
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
More information about the pulseaudio-discuss
mailing list