[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Wed, 2013-11-06 at 21:42 +0100, David Henningsson wrote:
> On 11/06/2013 06:52 PM, Tanu Kaskinen wrote:
> > On Wed, 2013-11-06 at 15:38 +0100, David Henningsson wrote:
> >> 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.

I'm very glad to hear that!

> 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?

OK, if exposing the mappings to the core is sufficient, then doing the
profile and port selection outside the node back-end is fine. However,
there are more cases to consider.

Bluetooth: how is the core supposed to know which profile to allocate,
when there is only one node for output that is used by both A2DP and HFP
profiles? My proposal is that the core calls pa_node_allocate(), with
"connection requirement" information (if you recall from my
presentation, connection requirements were things like minimum sample
rate). When executing the routing plan, the Bluetooth back-end knows
what was requested during the planning, so it can select the appropriate
profile in pa_node_activate().

Allocating other resources in ALSA than just ports: if there is limited
amount of DSP processing capacity, the capacity should be reserved
during the planning phase. For this pa_node_allocate() seems like a good
solution.

In general, it seems to me that doing resource allocation in the node
back-end is the right thing to do, because the core doesn't necessarily
have information about all resources in the back-end that affect the
node availability.

-- 
Tanu