[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Fri, 2013-11-08 at 06:49 +0100, David Henningsson wrote:
> On 11/07/2013 07:27 AM, Tanu Kaskinen wrote:
> > On Wed, 2013-11-06 at 21:42 +0100, David Henningsson wrote:
> >> 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.
> 
> The other way to go is to make that information available to the core. I
> think that would be a better way and allow for more reuse between
> backends, e g, your bluetooth example could very well apply to some ASoC
> scenarios too (when I was working with the Nexus 4 it had one PCM for
> low latency and another PCM for higher latencies).

Making a one-size-fits-all data structure for codifying all different
kinds of resources from all back ends has the potential of becoming very
complex thing to deal with, while leaving the node allocation to the
back ends allows the back end to only care about as much complexity as
is required by that particular back end. For handling just Bluetooth and
ALSA a one-size-fits-all solution is probably fine, but there's a
definite risk of needing to move this logic to the back ends later.

> For handling DSP processing capacity, I'm not sure what is the best
> solution, because there are too many missing pieces. Are you planning to
> implement that in the ALSA backend? A new type of backend? Or was it
> just a random thought?

It's more than a random thought, but not very much so. It's a thing that
we will pretty certainly need to handle at some point.

-- 
Tanu