[pulseaudio-discuss] Heads-up: the routing patches will start to get merged soon

[Tanu Kaskinen]

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

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

-- 
Tanu