> >In recent releases the stream routing logic is performed by >module-stream-restore and there is a way to inject "rules" into this >module which can act on "properties" attached to the streams. > >e.g. a VoIP class may attach a property to tell pulse that is is of >class "voip" and a rule could be written that says when a device stream >of class voip is played and a device of type headset is discovered, move >the stream across. > >I'm not sure if it handles the "moving after the stream has started" >case yet, but certainly this is the right approach and the stream >properties give the necessary meta-data to work with. > >This properties system was only introduced in pulse 0.9.11 which is why >Erik could not do this in the past and used a series of scripts. > >The docs for stream-restore are a little light just now but the >interface can be found here: > >http://0pointer.de/lennart/projects/pulseaudio/doxygen/ext-stream-restore_8 >h.html > >Pulse itself offers all the necessary hooks to know when a new device is >added and you should certainly stay away from module-hal-detect and >*-discover modules (there are also zeroconf-discover and, now, >raop-discover too!) as these is not a mandatory modules and sinks/source >could be added manually too. The hooks in pulse for when a new >sink/source is added/disappears is sufficient to do this kind of routing. > >I know this is a bit of a piecemeal reply as I don't fully know the ins >and outs of using the stream restore system. I just know it's the right >horse to back in the race rather than trying to do stuff at a lower level. > >Hopefully Lennart can give a more complete answer on stream-restore :) > >Col > [Zhang, Xing Z] It's really COOL! I will get an understanding of how stream-restore works first, then we may find a way to inject more "rules" into. Anyway you point out a right direction, great thanks!
