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

[Alexander E. Patrakov]

13.06.2016 01:36, 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?

Scratch that. It was based on my misunderstanding. I incorrectly thought 
that the patch changes the call chain that leads to card_set_profile(), 
and there is "if (u->use_ucm)" there. The new u->linked field guarantees 
that card_set_profile() is not called prematurely, so my concern was 
completely unfounded. The patch is OK.

-- 
Alexander E. Patrakov