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

[Arun Raghavan]

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?

-- Arun