[pulseaudio-discuss] RFC stream-restore save_sink|source flag reset & more musings on device selection.

[Lennart Poettering]

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