[pulseaudio-discuss] [PATCH 21/23] Introduce pa_router

[Tanu Kaskinen]

On Tue, 2013-11-26 at 13:40 +0100, David Henningsson wrote:
> On 11/25/2013 09:11 AM, Tanu Kaskinen wrote:
> > On Mon, 2013-11-25 at 04:50 +0100, David Henningsson wrote:
> >> On 11/20/2013 10:26 AM, Tanu Kaskinen wrote:
> >>> Router modules will create a pa_router object, and extend its
> >>> functionality with callbacks. There can be only one router in the
> >>> system at a time. At this first stage, the only functionality the base
> >>> pa_router is to notify the router modules about new and removed nodes.
> >>
> >> Then there is another concept we can take away to keep it simple atm -
> >> there is no need to have a "base pa_router", you can just notify the
> >> router implementation through hooks instead.
> > 
> > One point of pa_router is that it's ensured that there's only one router
> > loaded at a time in the system. That's useful, because a router is
> > responsible of managing all stream routing and profile and port
> > activation, so having two routers in the system would make the behaviour
> > unpredictable when those two routers conflict.
> 
> We currently have a system where several modules to their own part of
> the routing. I'm not saying it's perfect, but it's quite flexible. If
> only one router can be active at a time, that sounds less
> flexible/configurable.

Currently we have a bunch of modules that each handle certain small
tasks, like rescuing streams when the device goes away, or changing
routing when a device becomes available. If a module wants to implement
a policy where each stream has a prioritized list of devices and each
stream always plays to the highest priority device that is available,
then the router will have to take care of all those little cases that
are currently handled by separate modules. I don't see separate small
routing policy modules as a viable approach in the long term. As for
configurability, nothing prevents having a configuration file for a
router module.

That said, I don't have any strict requirement to enforce the "one
router at a time" rule. If the user loads multiple router modules and
that results in unexpected behaviour, we can leave that to be the user's
headache to figure out what's happening.

> > Another benefit of a dedicated object is that it's easier to define a
> > proper interface for the routers. It's usually not documented what a
> > hook callback is expected to do. I failed with the naming and
> > documentation of the pa_router_add_node() function and the associated
> > callback, though. That really isn't any better than a hook in terms of
> > interface clarity. I should have named it
> > pa_router_set_initial_routing() or something like that, because setting
> > the initial routing for a node is what the router is expected to do.
> > 
> > One more benefit of not using hooks is that hooks can have just one
> > "call data" parameter. I extended the interface of pa_router.add_node()
> > yesterday:
> > 
> > int (*add_node)(pa_router *router, pa_node *node, pa_node **initial_connections, unsigned n_initial_connections);
> 
> Eh, I thought the router was supposed to determine and set the initial
> connections, but now it looks like you're sending the initial
> connections into the router instead...?

The connections passed here are only a request. The router is free to
ignore those parameters. I should have used name "requested_connections"
instead of "initial_connections".

An example: Let's say that there's a stream playing to headphones. Then
another stream appears, and the client wants to play to the speakers,
but the speakers and headphones can't be used simultaneously. The router
can now decide to prefer the older stream, so it fails the creation of
the new stream (or routes it somewhere else than what the client
requested).

-- 
Tanu