[pulseaudio-discuss] sink/source automatic switching policy between different devices

[Zhang, Xing Z]

>
>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!