[pulseaudio-discuss] Edinburgh Murphy meeting notes

[David Henningsson]

On 11/06/2013 06:52 PM, Tanu Kaskinen wrote:
> 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.

I'm understanding the concepts of first have a planning phase and then
an execution phase. It seems reasonable.

But which ports are in conflict with each other is also something that's
visible to the core today - it's given by the simple constraint that
every sink/source can have one port active only.

In the case of having more than one sink (or source) per profile, maybe
we need to make some more information available to the core to make it
understand which port belongs to which sink. That seems to be a useful
addition, that would be reasonably straight forward to implement, I think?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic