RCF: Public API for managing nodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux