[pulseaudio-discuss] Edinburgh Murphy meeting notes

[David Henningsson]

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.

It's as simple as that today, so the core routing system would be
perfectly capable of carrying out that operation.

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