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.
