[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Fri, 2013-11-01 at 07:28 +0100, David Henningsson wrote:
> On 11/01/2013 02:08 AM, Janos Kovacs wrote:

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

> > Colin 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 guess one of the concern was whether the routing group should be part of
> > the core or not.
> > 
> > Routing groups conceptually are somewhat close to the priority lists
> > proposed
> > by Colin originally. The implementation is quite different, however. The
> > other important
> > concept was to find the right list  (routing group) to be used based on the
> > stream properties. We proposed somewhat simpler and less generic mapping
> > based
> > on the media.role property + the zone.name <http://zone.name> property
> > (which is new).
> 
> To have a zone.name property (on ports? or streams? or nodes?)
> intuitively sounds like a good idea, if the routing system needs this
> information.
> 
> > 
> > In my proposal routing groups are defined by two function, one which is
> > used decide
> > whether to add a node to the group and another comparision function to
> > maintain
> > the order of the nodes. Routing groups supposed to be defined by the
> > routing module
> > and consequently the routing module should provide those functions. This
> > is somewhat
> > more complex than the originally proposed priority list but not much.
> > 
> > Routing groups could be implemented completely by the routing module, so
> > if the verdict
> > is not add core support for routing groups is completely fine IMO.
> 
> So if this property it's something internal to the murphy module, then
> I'm likely fine with that module adding/modifying a zone.name property -
> but anyway; if we work in iterations, we're probably a few iterations
> from having this property added, so we can sort that out the details later.
> 
> 
> > 
> > Colin wrote:
> >> 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.
> >>
> >> I guess I'm just still not super comfortable with the need to have so
> >> much exposed outside of the implementation module itself.
> > 
> > Connections, as Tanu proposed them, are somewhat new (ie. we do not have
> > them in Tizen-IVI). I guess those also could be implemented in the
> > routing module if
> > we decide so.
> > 
> > So if needed we could start with only nodes + some extra hooks in the core.
> > However, node implementations should be added to ALSA, BT and other modules
> > IMO.
> 
> Please avoid touching the backend modules as much as you can. Ideally,
> I'd like the ALSA and BT modules to just add properties (or similar
> information) to indicate to the core and the routing system what it
> needs to know.
> 
> Otherwise we'll just end up copy-pasting code between different backends.
> 
> > David wrote:
> >>            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.
> > 
> > This is a valid concern. From the comments/judgements I see that we went
> > too far already ... The plan was to get a working proto and then break
> > it into smaller
> > understandable units that could be reviewed.
> > 
> > This is mostly my fault, since I did not want to propose/review
> > something that might
> > turn out inadequate in later phases. I hope Tanu will also comment on
> > this :)
> 
> That's always a balance, of course, and I understand this point of view
> too. In my experience, to try to keep things simple (as few concepts as
> possible) and then try to cover the corner cases by either tweaking the
> existing concepts, adding a special property or something like that, is
> more likely to be maintainable, compared to trying to think of all
> corner cases and come up with logical model that covers them all.
> (Because such a logical model will be very complex in itself and is
> likely to have its own set of corner cases anyway.) YMMV.