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

[David Henningsson]

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