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
