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
