[pulseaudio-discuss] [pulseaudio-commits] 6 commits - src/modules src/pulsecore

[Tanu Kaskinen]

On Tue, 2015-08-25 at 19:50 +0530, Arun Raghavan wrote:
> On 21 August 2015 at 17:11, Tanu Kaskinen <tanuk at kemper.freedesktop.org> wrote:
> [...]
> > +    /* XXX: If this is a headphone jack that mutes speakers when plugged in,
> > +     * and the headphones get unplugged, then the headphone device must be set
> > +     * to unavailable and the speaker device must be set to unknown. So far so
> > +     * good. But there's an ugly detail: we must first set the availability of
> > +     * the speakers and then the headphones. We shouldn't need to care about
> > +     * the order, but we have to, because module-switch-on-port-available gets
> > +     * separate events for the two devices, and the intermediate state between
> > +     * the two events is such that the second event doesn't trigger the desired
> > +     * port switch, if the event order is "wrong".
> > +     *
> > +     * These are the transitions when the event order is "right":
> > +     *
> > +     *     speakers:   1) unavailable -> 2) unknown   -> 3) unknown
> > +     *     headphones: 1) available   -> 2) available -> 3) unavailable
> > +     *
> > +     * In the 2 -> 3 transition, headphones become unavailable, and
> > +     * module-switch-on-port-available sees that speakers can be used, so the
> > +     * port gets changed as it should.
> > +     *
> > +     * These are the transitions when the event order is "wrong":
> > +     *
> > +     *     speakers:   1) unavailable -> 2) unavailable -> 3) unknown
> > +     *     headphones: 1) available   -> 2) unavailable -> 3) unavailable
> > +     *
> > +     * In the 1 -> 2 transition, headphones become unavailable, and there are
> > +     * no available ports to use, so no port change happens. In the 2 -> 3
> > +     * transition, speaker availability becomes unknown, but that's not
> > +     * a strong enough signal for module-switch-on-port-available, so it still
> > +     * doesn't do the port switch.
> > +     *
> > +     * We should somehow merge the two events so that
> > +     * module-switch-on-port-available would handle both transitions in one go.
> > +     * If module-switch-on-port-available used a defer event to delay
> > +     * the port availability processing, that would probably do the trick. */
> > +
> > +    PA_DYNARRAY_FOREACH(device, jack->ucm_hw_mute_devices, idx)
> > +        pa_alsa_ucm_device_update_available(device);
> > +
> 
> I'm really not happy about the idea of module-alsa-card needing to
> know about switching order in module-switch-on-port-available (or in
> general have knowledge of unrelated modules in any module if
> avoidable).
> 
> Doesn't it make sense to fix module-switch-on-port-available to work
> correctly in the second case?

Yes it makes sense. I just haven't got around to doing that yet, even
though the fix might end up being very simple (just move the state
change processing in module-switch-on-port-available to a defer event).

-- 
Tanu