[pulseaudio-discuss] Edinburgh Murphy meeting notes

Tanu Kaskinen tanuk at iki.fi
Tue Nov 5 14:40:55 CET 2013


On Fri, 2013-11-01 at 03:08 +0200, 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 property (which is new).
> 
> 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.
> 
> 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.
> 
> 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
> :)
> 
> br
> -janos-



More information about the pulseaudio-discuss mailing list