[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Thu, 2013-10-31 at 10:47 +0000, Colin Guthrie wrote:
> 'Twas brillig, and Tanu Kaskinen at 28/10/13 19:55 did gyre and gimble:
> > I got the criticism about routing groups - if there are other concepts
> > that you find questionable, please let me know.
> 
> I think this is more just a "general worry". There are a lot of new core
> concepts being introduced to achieve the end result and from the queries
> and questions asked, I got the impression that the people with PA
> background present were somewhat nervous about this, but perhaps I
> picked up and generalised things too much?
> 
> At the moment, the routing is very simple. Too simple (obviously!) but
> at least it keeps it manageable and understandable right now. I guess my
> main concern is that it will turn even very simple routing
> configurations into a very complex beast.

In the proposed system with routing groups, writing a new policy module
would require the following:

* defining the prioritization of routees
* assigning each routee to a routing group
* defining the rules of accepting routing targets to routing groups
* prioritizing the routing targets within routing groups

Fulfilling those tasks shouldn't be very complicated. However, my first
attempt at implementing the fallback policy (routing everything to the
default sink/source) turned out to be very complicated due to the
mismatch between the sink and node concepts. Everything else was simple,
but prioritizing the routing targets was hard. I have an idea for a
different approach for the fallback policy implementation, which I hope
will fit this model better.

So, simple policies *should* be reasonably simple to implement, but
there is a prior example that justifies the concern that this isn't
always the case.

The routing groups don't need to be in the core - the implicit routing
algorithm (which is the thing that interacts with the routing groups)
could easily be implemented in modules instead. I don't think this will
make the system any simpler, though. The old routing model is "hey, a
new stream appeared, what's the best sink for it?". The new model is
that whenever something happens, the routing system has to answer the
question "given all nodes in the system, what connections should exist
between them?" The routing groups are a tool for answering that
question, and I don't see much room in simplifying it (ideas are
welcome, of course).

> I asked during the meeting about if "connection" core concept was
> needed. This was justified that it would be needed to do things like
> loading loopback modules, combine modules or remap modules to join
> things up as needed. This is a reasonable justification, but after some
> reflection I cannot see how this can be a core concept as it has to have
> implicit knowledge of the modules. If core is loading specific modules,
> then those modules are not really modules any more as they are needed by
> the core.

Indeed, the core should never load any modules except when requested by
some external entity. The proposed solution to this problem is to move
the loopback, combine sink and null sink implementations to the core so
that they can be used without loading any modules.

The connection concept originated when discussing the client API with
David. He thought that the implicit and explicit flags should really be
an attribute of the connection between two nodes, instead of storing
that information in the nodes. I agreed, and later we (me and Janos)
realized that connection objects will be very useful at the server side
too.

-- 
Tanu