On Tue, 2014-04-22 at 10:06 +0100, Colin Guthrie wrote: > Hiya, > > 'Twas brillig, and David Henningsson at 22/04/14 09:41 did gyre and gimble: > > On 2014-04-17 12:41, Tanu Kaskinen wrote: > >> On Fri, 2014-04-04 at 15:50 +0200, David Henningsson wrote: > >>> On 04/04/2014 11:31 AM, Tanu Kaskinen wrote: > >>>> I'm heading towards "a generic solution to our current routing issues", > >>>> but that solution will depend on Murphy, which will provide the > >>>> configurability and the default routing rules. In my opinion, > >>>> implementing another solution with good configurability and > >>>> better-than-current default routing without Murphy should be > >>>> implemented > >>>> by someone else, if a non-Murphy-based solution is desired. > >>> > >>> (Just summing up what we discussed on IRC) > >>> > >>> So the result from all this work is that normal desktop users will get > >>> nothing, except an API and quite some infrastructure to maintain. > >>> > >>>> If I understood correctly, you wish that I'd implement a full generic > >>>> non-Murphy-based solution before merging the node infrastructure, but > >>>> it's unclear to me whether that wish is a minimum requirement or not, > >>>> and if it's not, what's the minimum requirement? > >>> > >>> I'm not sure what to answer to this question right now. I'd like to hear > >>> what others have to say as well. > >> > >> Others were silent, so in the absence of permission from you to do > >> anything else I think I'll have to work with the assumption that I will > >> need to provide some kind of configurable non-Murphy-based routing > >> module before the routing infrastructure can be accepted to master. > > > > Well, I'd much prefer to hear more opinions about it. It's difficult for > > me to know as well. > > Sorry, I've been somewhat slow to comment on this. > > > Is there a simple summary of the hooks etc. added by the Murphy patches > that would be available to said alternative routing system? By "Murphy patches" I assume you mean the node infrastructure patches that I have sent to the mailing list so far. I'll try to give a simple summary: There are two new "classes": nodes and edges. At this point only the initial routing of streams is handled through the node/edge interface, moving streams still has to be done with the old interfaces. As for hooks, there are a few new ones: - PA_CORE_HOOK_NODE_SET_INITIAL_ROUTING - PA_CORE_HOOK_DEVICE_SET_PORT - PA_CORE_HOOK_CARD_SET_PROFILE There's no NODE_PUT and NODE_UNLINK hooks, because I haven't needed them so far, but they're trivial to add if you need them. The NODE_SET_INITIAL_ROUTING hook can be used for setting the initial routing of new streams. You can also continue to use SINK_INPUT_NEW and SOURCE_OUTPUT_NEW if you prefer. DEVICE_SET_PORT and CARD_SET_PROFILE can be used to intercept user-initiated port and profile changes, in case you want to do that. If you don't want streams to be killed when port or profile is changed, there needs to be some module that rescues the streams. There's a new module, called module-skoa-router, which is currently loaded by default, and it uses uses the hooks to rescue streams from the old port or profile to the new port or profile, and that's currently all that module does. > As you know there is routing functionality built into the > module-device-manager module which is used under KDE. > > With not too much effort, (I've recently done some of this work in > unpushed changes), I wanted to adapt this current device-centric routing > to be more device-port based (allowing priority list of: > > 1. Headphones (via built in jack) > 2. USB Speakers > 3. Laptop speakers > > where 1 & 3 are the same sink, just different ports) > > > Once this is done, I think it could also be the default routing module > used on GNOME (and would solve > https://bugzilla.gnome.org/show_bug.cgi?id=728592 too in the process). > > With this in place, it would only take a little effort to port some of > the specific functionality modules (e.g. using BT/USB headsets for phone > calls etc) to inject device into the routing tables used by m-d-m > appropriately rather than actively moving streams. > > Obviously if the Murhphy patches add nice APIs for "rerouting" and such > like then m-d-m should be ported across to it at the same time. There's no such functionality at this point. > I know I'm not really active these days, but if this is something you > want to discuss, I can make myself available for a meeting to discuss > more and also potentially commit to doing some more work on it if there > was a very specific goal and plan in mind with a view to merging etc. > > Also happy to make the necessary API changes on the KDE and GNOME sides > too to interface with this as appropriate (likely quite minimal changes > on both sides). > > Let me know if you want to chat more. Currently module-device-manager doesn't get much benefit from the node infrastructure, so it might make sense to wait until more functionality has been implemented. I don't have a strong opinion on this, however - if you want to work on module-device-manager now, I'm fine with it. -- Tanu
