Yes it is. The sound service uses the asynchronous PA API to control and monitor the sound device(s) responding to external intervention (i.e. another application muting or changing the volume or a device being removed or inserted etc.).It would appear that since the the daemon can change the routing, that controllers necessarily should have the ability to register for change events. Is this not the case with the current PA implementation?
The problem that Ara has outlined is a tad more involved though. It stems from the disjoint between the default device mindset and Pulse's multiple streams multiple devices setup. Essentially in order to identify this particular case I will need to do maintain a cache of 'active clients' and their target sink. And at the point of sink swap infer from both client generic callbacks, source output info and source info callbacks that a sink index has changed for a client we are interested in which previously had the default sink as its target sink.
Thats my strategy for now. Conor -- Conor Curran Desktop Architect Sound Engineer Desktop Experience team Canonical Ltd Email: conor.curran@xxxxxxxxxxxxx web: http://www.canonical.com