[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Fri, 2013-11-01 at 11:58 +0200, Janos Kovacs wrote:
> On Fri, Nov 1, 2013 at 8:28 AM, David Henningsson
> <david.henningsson at canonical.com> 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.
> 
> Actually, the zone property has much to do with systemd seats. So, we might
> end up to change the terminology and call them as seat.
> 
> Zones (or should I say seats) are properties of streams, ports, and
> nodes as well.
> The idea was that the apps can specify the zone for their stream or in
> the lack of
> that the routing module can add the zone property
> (pid of the stream -> systemd session -> seat). In cars there are
> security concerns
> as well, so routing modules supposed to check whether the app has right to
> play/record in the requested zone.
> 
> Systemd has already some support for device allocation for zones. However, this
> might not be sufficient for all cases. Think of a PCM, ie. a device,
> with 7.1 capability,
> that can be split between two zones, eg. a 2.1 zone for the desktop machine that
> runs PA, and a stereo zone for the living room. We would need to load
> extra remap sinks
> and add the zone property to them. In this case the zone can't come from systemd
> automatically, we would need some extra configuration data somewhere. So, either
> we could set the property directly in default.pa, if we load the
> module that way, or
> the routing module should take care of this if that would set up the
> remap sinks.
> 
> We also need to think of the distros that do not have systemd.
> 
> >
> > >
> > > 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.
> 
> You could say it is internal to the routing module, and as I tried to point out
> above, there is no need to set it in the core. Would be nice to have a
> definition
> for it in the property-list header :)
> 
> >
> >
> > >
> > > 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.
> 
> To implement certain node related operations and store node specific data I see
> two basic ways:
> 
> 1.) a kind'a object oriented approach, ie, the node related backend
> specific stuff
>      is added to the backend with some supporting common functions in the core,
>      if we would need any. That is what we choose for the PoC Tanu works on.
> 
> 2.) The node stuff is done in a layer top on the existing
> infrastructure. This extra
>       layer can be implemented in the routing module. That's how the TIZEN-IVI
> However, the current PA
>       core infrastructure lacks certain things what makes the implementation of