[pulseaudio-discuss] [PATCH 00/11] Routing: Move routing policy code out of module-alsa-card

[David Henningsson]

On 11/24/2013 07:48 AM, Tanu Kaskinen wrote:
> On Sun, 2013-11-24 at 07:57 +0200, Tanu Kaskinen wrote:
>> module-alsa-card does currently a bit of routing: it moves streams
>> during profile switches with the goal of keeping streams connected to
>> the same card before and after the profile switch. This doesn't
>> belong to module-alsa-card, it should be in a policy module, so this
>> patch set removes that code from module-alsa-card.
> 
> I'll start writing the next patch set now. To ensure that reviewers are
> happy with the scope of the next patch set (there have been problems
> with the scope in the past), I'd like potential reviewers to ack or nack
> the following plan (the sooner the better):

I don't know if I count myself as a potential reviewer at this point;
both due to the lack of time, and the general feeling that this is
getting too big and complex already, but anyway...

> Currently module-experimental-router sets the initial sink of a sink
> input directly, but the routers shouldn't need to care about whether the
> nodes are sinks or ports or sink inputs or whatever, and this is what
> I'd like to work on next. 

My gut feeling is "nak, at least for now".

I think that if the router currently sets the sink of a sink input
directly, that sounds like a reasonable middle step. So before carrying
away even further, let's look at where we are now:

 1) Is the current patch set doing anything of value?

 2) Does it add any new functionality that we did not have before?

 3) And just a side question, out of personal interest - we've had
problems that the sink for a sink input switches during a S3, because
the USB or Bluetooth stack is not completely up when PulseAudio returns,
so to PulseAudio it looks like the card is disconnected and then
connected again.
Do you have any thoughts about this problem and how the new routing
infrastructure would help?

> How should the initial sink for a sink input
> be set in the brave new node-based world? I think this should happen as
> part of creating a new connection object. So, I want to introduce the
> connection objects.

Also, I don't see how this would help. I mean, I can understand that
it's useful to have connection objects (e g to distinguish between
automatic and manual connections - this is a property of the
connection), but why would connection objects be better candidates to
call pa_sink_input_* than routers?

Or to put it in another way, you say that "routers shouldn't need to
care about whether the nodes are sinks or ports or sink inputs or
whatever". I question this claim and wonder why connection objects
should be the ones to care instead?

If the reason is to avoid code duplication between
module-experimental-router and module-murphy-router, then maybe just
doing a, say

pa_node_connect(pa_node *from_node, pa_node *to_node)

...could deal with performing this internally - it still isn't a reason
to add connection objects.

> Who manages and owns the connections? If there's no router, the core
> will of course need to manage the connections. The natural owner for
> sink input connections in this case is pa_sink_input. If there is a
> router, then connections may be created by the router, and I think it
> makes sense in that case to make the router also the owner of the
> connections, so freeing the connections is then also the responsibility
> of the router. Hopefully it won't become too complex to tell apart
> connections owned by the core and connections owned by a router.

I previously suggested that we would just have a long list of
connections in a simply linked list, and that linked list would be added
to and removed from by the core, maybe inside the node code.

There are no other pointers to these connection objects from anywhere
else (this is to prevent dangling pointers) - just a simple lookup
function that returns the connection object given a from_node and to_node.

It sounds like you instead want to spread memory management of the
connection objects all across the place, which sounds very error prone.


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