'Twas brillig, and Tanu Kaskinen at 29/11/11 18:53 did gyre and gimble: > On Tue, 2011-11-29 at 09:22 +0000, Colin Guthrie wrote: >> 'Twas brillig, and Janos Kovacs at 28/11/11 14:52 did gyre and gimble: >>> However, what hook could be used to compose the 'media.role-zone' >>> property? In the proposal (ie. the patches) the routing is done before >>> PA_CORE_HOOK_SINK_INPUT_NEW is called, so I guess that cannot >>> be used. >> >> >> Yeah I think I mentioned this chicken+egg on the wiki (or if I didn't I >> had it in my head and *meant* to mention it!). >> >> The problem is currently that module-stream-restore happens during >> PA_CORE_HOOK_SINK_INPUT_NEW and as a result may assign a sink to a >> stream which would mean that we wouldn't do the routing (i.e. for the >> same reason that we wouldn't want to do any routing if they caller >> specified a specific device to use when they connected their stream). >> >> But this can be changed, and if we remove (or disable-by-default) the >> restore-device part of module-stream-restore then the routing can happen >> after PA_CORE_HOOK_SINK_INPUT_NEW hook and thus the property can be written. > > I'm not sure I understood your plan. Do you intend to change the ROUTE > hook firing to happen after NEW? And since module-stream-restore would > in this case interfere with modules that do priority list routing, you'd > disable the routing part of module-stream-restore by default? I guess > that could work. Yup, exactly that. > What's the default routing module going to be, if the routing part of > module-stream-restore gets disabled? Do you plan to write something from > scratch? I intend to have three priority list modules, default, application and role We attempt to route by role first, if that fails we try application and finally we try default. I'll probably also write some compatibility code that imports the stream restore database to ease upgrades. > What about other modules that affect routing in the NEW hook? Do they > pose a similar problem as module-stream-restore? If so, are they going > to be disabled also by default? If so, what's going to replace them? There are not many of them. module-device-manager is one obviously one which is totally obsoleted by this approach so it'll just get nuked (again, I may try to import the data on first run to smooth upgrades). The others are intended-role which I've covered by previous emails and on the wiki. So we're down to only a the filter modules now I think which shouldn't be too hard to accommodate (it does need more thought generally anyway - e.g. it might be sensible to never actually letting the virtual filter devices get written to a priority list and have some other system that automatically uses the sinks virtual equiv based on other criteria (such as the filter.wants properties on the streams). So filter stuff is trickier but certainly not impossible (and it's something that I kinda had in mind anyway when I wrote the initial versions of the filter stuff) Have I missed any other modules? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
