On Thu, 2013-10-31 at 14:28 +0100, David Henningsson wrote:
> On 10/31/2013 11:47 AM, Colin Guthrie wrote:
> > 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.
>
> I agree with Colin here.
>
> But I would like to add something that's even more important: to get
> these PA routing patches in digestible chunks. I've tried to say this
> ever since Janos and Jaska started working on it more than a year ago,
> but the message seems not to get through. It feels like there is a giant
> patch set being worked on by Tanu, and having this giant patch set
> presented all at once leads to significant risks:
The plan was to not present it all at once, but in smaller pieces.
However, this would be done only after we have a proof of concept
implementation that actually works.
> * The review will be extremely heavy. Nobody will bear to do it.
>
> * We might want to rethink things in the beginning of the patch series,
> which leads to a lot of things having to be rewritten.
Doing the full implementation first and then presenting it piece by
piece doesn't help with your second point, so yes, your concern is fully
justified. It would be better to actively involve the community in the
design discussion already before we have a proposal ready for a full
system. That's how I tried to work in the beginning, but Janos wanted to
get the full system working ASAP. The reason for that was, in my
understanding, that there is some schedule pressure for porting the old
Murphy module in Tizen on top of this new routing system. If the new
system is not fully functional (or lacks necessary features), the
porting can't be done. If the design is done iteratively with the
community, it will take too long to reach the fully working state.
So, it's the usual problem of doing stupid things due to time
constraints. What's the way forward? I talked with Janos and Jaska, and
we agreed that I'd start sending out patches now, even though the
backend support for node allocation during planning is incomplete, and
the routing plan execution (connection building) is mostly
unimplemented. I don't know how that will work out schedule-wise, so
perhaps the plan will change again...
These are the critical points identified by Janos that I should try to
get to upstream ASAP (like within a month) to facilitate the Murphy
module porting:
- The node structure (this is already done, although in a separate
branch).
- Backend implementation for nodes (this is already almost done,
although in a separate branch).
- Support for two-phase routing (i.e. the idea that first we create
a routing plan, and only after that's complete, we do the actual routing
actions). I need to discuss with Janos again what he meant with this,
because this item sounds unrealistic with all the missing code for
connection building. It might be that it's sufficient if I manage to
convince you that we really need this, so having the implementation
ready isn't that critical.
- Either install the core headers for supporting out-of-tree
modules, or get the Murphy module to upstream. I need to clarify what
the actual requirement is. It might be that what is really needed is an
agreement that upstream is not fundamentally opposed to having the
Murphy module in upstream as an optional module (implying optional
dependencies to Murphy and Lua). Tizen has carried patches for enabling
out-of-tree modules so far, so what's the problem with keeping doing
that?
> To be a bit more constructive, let me give you an example of how to
> instead work in iterations. See it just as an example, because it does
> not take into account the work already done (and I don't know the
> details as well either).
> In this example, in every step, there would be a review and merge into
> the main branch of PulseAudio.
>
> Step 1) Introduce node concept. We need only to create nodes for streams
> and ports at this point (because we're not sure whether to add a port to
> sinks which does not have one).
> Make an extremely simple router which just routes to the default
> sink/source.
>
> Step 2) Improve router so that it also replaces the work of
> module-device-restore and module-stream-restore.
>
> Step 3) Improve router so that it also replaces the work of
> module-switch-on-port-available.
>
> Step 4) Add an API which makes it possible to route from a node to
> another. Again, just focus on the most common cases first, we can return
> -ENOIMPL if the user uses the API for something we don't support at this
> point.
>
> Step 5, 6 etc) Improve the routing engine to handle more and more cases,
> including automatically loading loopback modules etc.
>
> ...and so on. Working in iterations might cause a few detours along the
> way, and we might not end up where we think we would when we started,
> but probably somewhere better.
I'd imagine the steps with incremental development would be more like
this:
1) Add a flag in the core, which indicates whether pulseaudio should use
the old routing model or the new one. Check the flag wherever someone
tries to set pa_sink_input.sink or change a port or profile. If the flag
is set, fail the attempted operation. The flag would be controlled by a
special module, so if that module is not loaded, everything works as it
used to, and if that module is loaded, nothing works.
2, 3, 4) Add the core routing infrastructure piece by piece.
5, 6, 7) Add the backend support.
8) Implement the fallback policy (default sink/source routing).
9, 10, 11) Fix what was broken at step 1. I would hope that
module-stream-restore and other old routing modules could become
functional at this point, without actually needing to do big changes to
those modules (for example, when module-stream-restore sets the sink for
a new sink input, that could be automatically mapped to an explicit
connection request).
12) Remove the flag from the core and the special module, they have
become unnecessary.
13) Add module-murphy.
14) Maybe replace module-stream-restore and friends with some new
module(s).
The order of the steps can be almost anything, except that step 1 should
be the first one and step 12 can't be very near the beginning.
My point is that it may not be possible to have a linear progression
from a "simple system" to a "complex system", like in your example. I
don't want to design and implement core infrastructure in the middle
that I know won't scale to what we will need to be able to handle.
--
Tanu
