[pulseaudio-discuss] [PATCH v2 2/9] dbus: Track the default sink and source with hooks

[Tanu Kaskinen]

On Mon, 2013-03-18 at 16:21 +0100, David Henningsson wrote:
> On 03/18/2013 04:15 PM, Tanu Kaskinen wrote:
> > I guess you mean this: the D-Bus code has its own default sink variable,
> > let's call it dbus.default_sink here. dbus.default_sink is always the
> > same as core.default_sink when core.default_sink is non-NULL.
> >
> > When core.default_sink changes to NULL, the D-Bus code calls
> > pa_namereg_get_default_sink() and saves the result to dbus.default_sink.
> > If that causes a change to dbus.default_sink, a signal is sent.
> >
> > When someone queries the property value and core.default_sink is NULL,
> > pa_namereg_get_default_sink() is called again, the result is stored in
> > dbus.default_sink and the if that causes a change to dbus.default_sink,
> > a signal is sent. Then the result is sent as the reply to the original
> > query.
> >
> > This would indeed achieve the desired consistency between the signals
> > and the property query results. I'll implement this, unless this
> > question causes you to change your mind:
> >
> > Does it really make sense to return a fallback sink when queried, if
> > there's no signal sent when the "ad-hoc default" changes? This applies
> > to the native protocol as well. Let's use pavucontrol as an example. It
> > shows the current default sink. If core.default_sink is NULL, the
> > default that pavucontrol shows is the highest-priority sink at the time
> > of the initial pa_context_get_server_info() call. If a higher-priority
> > sink appears, pavucontrol won't get a signal about the change in the
> > "ad-hoc default" sink, so it will end up displaying incorrect
> > information. Would it be better to not show any sink as being the
> > default, when the default hasn't been explicitly set?
> 
> Ok, fair point. It sound like you need to update (and possibly signal) 
> dbus.default_sink when sinks are added and removed too, then? Are there 
> other events that can cause the result of pa_namereg_get_default_sink to 
> change, so that pa_namereg_get_default_sink() and dbus.default_sink get 
> out of sync?

Assuming that sink priorities can't change at runtime, then the default
sink can change only when sinks are added or removed (based on the
current pa_namereg_get_default_sink() implementation).

As I said, this problem is not really D-Bus specific, so the solution
shouldn't be D-Bus specific either. I propose that we add a new
variable: pa_core.configured_default_sink, which behaves as
pa_core.default_sink behaves currently, and we change
pa_core.default_sink so that the namereg updates it whenever sinks are
added or removed if pa_core.configured_default_sink is NULL (if it's
non-NULL, pa_core.default_sink is the same as
pa_core.configured_default_sink).

-- 
Tanu