[pulseaudio-discuss] Edinburgh Murphy meeting notes

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Wed Nov 6 14:37:55 CET 2013

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.


More information about the pulseaudio-discuss mailing list