On Fri, 05.02.10 10:11, Colin Guthrie (gmane at colin.guthr.ie) wrote: > Hi, > > Recently I tried to write a client that would nuke the device part of > the stream restore database. > > This works fine but any active streams that match the rule will not have > their save_sink|source flag reset when this happens. > > I think the following patch does this but just wanted to double check > this wouldn't trigger some other unwanted behaviour (e.g. in gnome apps) > before I push it. > > I also generate a sink input|source output change subscription message > here. This is arguably not "correct" as the sink input itself is not > changing, although the rules governing it's routing have. In lieu of a > proper subscription system for "routing rules" I just fire this one. > > Comments? > > http://colin.guthr.ie/git/pulseaudio/commit/?id=7a7c7e53914f641686fe3fe59d0772e78cdf86ca Hmm, we actually try pretty hard to supress subscription events if we can. Since the only thing you change about the sink input is the save_sink flag I see no reason to fire the event. The primary purpose of the subscription event is to notify clients about changes, but they have no access to the save_sink flag at all. I'd advise to not fire the subscription event here, unless an existing module really needs this. (Though generally I am tempted to say that modules that care about save_sink and the routing stuff should use synchrnous hooks rather than asynchronous subscriptions) But otherwise the patch looks fine to me, and makes a lot of sense to me. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
