[pulseaudio-discuss] [PATCH v2 3/6] card: move profile selection after pa_card_new()

[Tanu Kaskinen]

On Sun, 2016-06-12 at 18:33 +0500, Alexander E. Patrakov wrote:
> 10.06.2016 22:55, Tanu Kaskinen пишет:
> > I want module-alsa-card to set the availability of unavailable
> > profiles before the initial card profile gets selected, so that the
> > selection logic can use correct availability information.
> > module-alsa-card initializes the jack state after calling
> > pa_card_new(), however, and the profile selection happens in
> > pa_card_new(). This patch solves that by moving parts of pa_card_new()
> > to pa_card_choose_initial_profile() and pa_card_put().
> > 
> > pa_card_choose_initial_profile() applies the profile selection policy,
> > so module-alsa-card can first call pa_card_new(), then initialize the
> > jack state, and then call pa_card_choose_initial_profile(). After that
> > module-alsa-card can still override the profile selection policy, in
> > case module-alsa-card was loaded with the "profile" argument. Finally,
> > pa_card_put() finalizes the card creation.
> > 
> > An alternative solution would have been to move the jack
> > initialization to happen before pa_card_new() and use pa_card_new_data
> > instead of pa_card in the jack initialization code, but I disliked
> > that idea (I want to get rid of the "new data" pattern eventually).
> > 
> > The order in which the initial profile policy is applied is reversed
> > in this patch. Previously the first one to set it won, now the last
> > one to set it wins. I think this is better, because if you have N
> > parties that want to set the profile, we avoid checking N times
> > whether someone else has already set the profile.
> 
> Looks OK to me, but I would like an extra confirmation whether in the 
> UCM case the sequence of mixer accesses is the same before and after the 
> patch.

That's a pretty specific concern. What makes you concerned about the
UCM case and not about the non-UCM case? This patch shouldn't affect
the mixer access pattern in any case, UCM or not. This patch only
postpones the initialization of pa_card.active_profile a bit: module-
alsa-card.c used to call init_jacks() after active_profile had been
initialized, now init_jacks() is called before active_profile is
initialized. init_jacks() doesn't depend on active_profile, so I don't
think this patch can cause any changes in the mixer access patterns.

-- 
Tanu