Hi Colin: On 12/22/2010 05:23 PM, Colin Guthrie wrote: > 'Twas brillig, and Cai Yuanqing at 22/12/10 06:25 did gyre and gimble: >> I wrote a patch to make the module-loopback unloading as bluetooth >> source was unavailable. >> >> In my opinion ,moving the source of source-output from a live source >> like A2DP source to default or any other ones dose not work.only >> module-loopback loaded and can not work any more. >> So I just want to make the module-loopback can not be moved when the >> source is a A2DP source of bluetooth. > > While this is Pierre-Louis Bossart's module and I'd like to hear his > opinion on it, I'm not personally a big fan of this kind of heuristic. > > If you care to add a new argument to the module called e.g. "dont_move" > that adds in the appropriate flag to the sink input or source output, > then I think this would be a better and more deterministic behaviour. It > would obviously only make sense when used with the source= or sink= > arguments. Thanks for your suggestion,I will try to add some arguments like this,It's a good way to avoid some bad effect we don't know so far. :-) >> BTW,I'm not sure that should we unload the modules when the source it >> using were unavailable in the other situations. >> Dose anyone have ideas for that? > I'm kind of of the same opinion. I prefer to see modules (and this > applies to others like remap, combine etc.) "idle" when their tightly > bound sink/sources are no longer available and then "kick in" > automatically when they appear. This kind of logic would allow for more > things to be added to a user's customised default.pa and automatically > work when appropriate. > > Col > Yes,but add the logic may need to change the logical of module-rescue-streams or we need a new module to do things right. -- B.R Cai Yuanqing
