On 04/04/2014 10:14 AM, Tanu Kaskinen wrote: > On Thu, 2014-04-03 at 21:34 +0200, David Henningsson wrote: >> On 04/03/2014 11:07 AM, Tanu Kaskinen wrote: >>> Hi all, >>> >>> There's a big pile of routing patches from me that haven't been merged >>> to master. Some of them have been reviewed and are in the "routing" >>> branch, and some (most) are pending review. The plan was that Arun would >>> review them, but it turned out that he doesn't have time for that after >>> all. It appears that nobody has time to review those patches, so to >>> avoid blocking the work forever, I plan to start pushing them to master >>> without waiting for reviews any longer. If anyone has objections or >>> questions about this, let me know. >>> >>> I don't expect the merging process to happen overnight, because >>> currently most of my time goes to the Tizen volume API, and there's >>> probably also significant amount of rebasing work to do (the routing >>> branch forked from master in September). >> >> When I stopped reviewing (mainly due to lack of time), the patches added >> more complexity than it solved actual problems. I tried to point that >> out repeatedly last year and help you back on track, but the latest was >> a "I give up" here [1]. If this situation has not changed significantly >> since, my opinion is that I don't we should merge anything of the >> routing work to master. This is because the cost of the added complexity >> weighs heavier than the benefit of added features (or solved problems). >> If it has changed significantly, could you give a summary on why I >> should re-evaluate this opinion? > > I don't think there's significant change. > > So you want to trigger merging only once there are significant benefits > for users. ...and those benefits outweighs the cost of the additional complexity of maintaining another node/edge layer. Which means that the more complexity you add, the more user benefit you need. > Peter and Arun, what's your opinion, is this a fair > requirement? What benefit would be significant enough? Which of these > (if any) would be sufficient? > > 1) Automatic port switching when an application wants to play to an > inactive node: "paplay --routing=some-inactive-port-node foo.wav" > > 2) Support for loopback routing without loading module-loopback > manually: "pactl set-node-routing some-input-port-node > some-output-port-node" > > 3) Support for automatic combine sink creation: "pactl set-node-routing > some-playback-stream-node output-node1,output-node2" > > 4) A Murphy module that uses nodes for routing > > 5) Non-Murphy routing module that does something smart (please define > "something smart") > > 6) Something else I was originally hoping for a generic solution to our current routing issues, such as making it easy to configure which (hotpluggable) devices/ports should be used in which scenarios, with a sensible default. Maybe some type of device priority order, like Colin Guthrie has suggested (and even implemented, but it was never merged). And for the bug where default sink/source can change after S3, to be fixed. But it does not look like that's the direction you're heading, or is it? >> But a related question, if it's suddenly okay to push complicated stuff >> without review, should I go ahead and push my Ubuntu phone stuff as >> well? It's been waiting for review for about half a year now. > > It appears to be rather self-contained, and doesn't add any public API, > so if you prefer pushing it now instead of waiting for review, I'm OK > with that. Ok, what does Peter/Arun think about this? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
