On Wed, 2013-11-06 at 15:38 +0100, David Henningsson wrote: > On 11/06/2013 02:37 PM, Tanu Kaskinen wrote: > > On Fri, 2013-11-01 at 07:28 +0100, David Henningsson wrote: > >> On 11/01/2013 02:08 AM, Janos Kovacs wrote: > >>> 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. > > > > I'm not sure what scenario you're thinking of with the copy-pasting > > note. The plan is to have important parts of the routing logic in the > > node backends, but I don't see that resulting in copy-pasting. The > > knowledge of how to activate nodes and how nodes conflict with each > > other is specific to the backend. For example, the details of connecting > > a cellular modem to speakers needs to be handled entirely within the > > backend. Even in more common cases it's necessary to leave resource > > allocation to the backend: > > > > * With ALSA, each profile can have multiple mappings and each mapping > > can have multiple ports. Each mapping can be part of arbitrary profiles > > and each port can be part of arbitrary mappings, so there can be many > > different ways to activate a single port. Activating a port means that a > > combination of a profile and a mapping needs to be selected. Mappings > > aren't visible outside the ALSA modules, so the logic for choosing the > > best profile and mapping combination for each to-be-activated port needs > > to be in the ALSA modules. > > > > * With Bluetooth, one port can have two very different modes. These > > modes aren't visible outside the Bluetooth modules, so the logic for > > choosing the best mode needs to be in the Bluetooth modules. > > Activating a port is done by selecting a profile on a card, then > selecting a port on a sink/source. > And all profiles, ports, and the relationship between them, are visible > to the core. Yes, if there is one stream that needs to be routed to a port, it's easy to just go ahead and activate the port. However, consider this example: there is a playback stream and a capture stream. There's an alsa card which is currently having the "off" profile active. The routing policy decides that the playback stream should be routed to the analog output port of the alsa card. But there are two profiles to choose from: analog-output+analog-input and analog-output+digital-input. If the profile is chosen randomly, it may be that the preferred source won't be available for the capture stream by the time the routing algorithm starts finding a target for it. If a different profile would have been selected earlier, both streams could have been routed to their preferred targets. This example doesn't actually prove anything regarding whether the port activation logic should be in the router or in the node backend. Instead, this example shows that we need to split the routing into two phases: planning and execution. In the planning phase ports are allocated, and if there are multiple ways to activate them, the final decisions are made only after all allocations have been done. Before the final decisions all available options are kept open. This is an essential aspect of the design, and I really hope I will be able to convince you that it's necessary. If I can do that, then it will become apparent that having access to the mapping objects is necessary in the planning phase, because otherwise you don't know which ports conflict with each other and which ports can be used at the same time. -- Tanu
