[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Thu, 2013-10-31 at 14:28 +0100, David Henningsson wrote:
> On 10/31/2013 11:47 AM, Colin Guthrie wrote:
> > 'Twas brillig, and Tanu Kaskinen at 28/10/13 19:55 did gyre and gimble:
> >> On Mon, 2013-10-28 at 17:50 +0000, Colin Guthrie wrote:
> >>> Generally, there was some degree of concern over the number of new core
> >>> concepts needed to support this and some questions were asked about
> >>> whether some parts are really internal to the routing algorithm
> >>> *implementation* itself, rather than the concept of routing algorithms
> >>> as generally supported in PA. We all agree we need a better routing
> >>> infrastructure, so the only question is really how many of the concepts
> >>> are leaks from the current Murphy-based implementation vs. genuinely
> >>> useful in the general case.
> >>
> >> 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?
> 
> Sorry for not chiming in earlier - I was on vacation and came back to
> work yesterday. And I wanted to talk to a few people before writing it, too.
> 
> Anyway, for me it's even worse than a general worry. After the meeting,
> I feel this stuff is growing out of hand.

(snip, Murphy discussion sent separately to murphy-dev)

> > 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 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.
> 
> 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 do feel the core
> > changes should be kept as limited as possible, with the minimum of hooks
> > and interfaces needed and the rest kept as private as possible to the
> > implementation itself.
> 
> I agree on this too. I'm not sure where the boundary goes between the
> core router functionality and module router implementations, but if we
> work in iterations, we can sort that out as we go.
> 
> Sorry if all of this comes as a cold shower for some of you. But I feel
> we really need to steer this PA routing project out of the over-complex
> and over-engineered trap which it seems dangerously close to falling
> into at this point.